Our security researcher Linus Särud explains why you need to realize that a vulnerability in an imported resource is as bad as a vulnerability in your own code.
The web community can be seen as awesome. With just a single line of code it is possible to include external scripts to add functionality to a site without having to write anything ourselves. Or, if we want to, we can include someone else’s code as a base and then write our own on top of that (with libraries, for example).
This is very common, and something that most sites do, this very blog being no exception. Fire up the web console right now and you will see a lot of external domains under Sources.
(We try to be as transparent as possible with the services we use, and you can get a list at https://detectify.com/services. Please observe that includes all the external services we use, not just included resources.)
I remember my first personal blog, and the ridiculous widgets I used without thinking about the security implications. It was everything from a kitten following the mouse pointer, making the whole blog snow to more useful stuff like a guest book (you could not have a blog without a guest book, unwritten rule).
Professional sites today might not use kittens that follow the mouse pointer that often, but the rest still stands. In our own example, we use it for the comment section here and it was the easiest way to implement all the share-buttons below this blog post.
With all these advantages it is easy to overlook the issues caused by including third party scripts, which is what this blog post focuses on. There are two main concerns to take into consideration and although there is no optimal solution to solve this, being aware of the risks can help us make more informed decisions.
Vulnerabilities
Vulnerabilities in third party scripts exist regardless of whether the script is hosted externally or not. This becomes a problem because hackers do not need to target you specifically – if they find a vulnerability in the code included, they can attack everyone that imports it, including you.
This also means that if someone were to target you specifically, they can search for vulnerabilities in the included resource that someone else has already found.
A great example of this problem is the XSS Mathias Karlsson found in AddThis. As the very same script is included on multiple domains this one vulnerability leads to an XSS on a million different sites.
It is not realistic to expect everyone to do a security assessment on each script imported, but there are a few bullet points to keep in mind to make better decisions:
- Realize that a vulnerability in an imported resource is as bad as a vulnerability in your own code. An attacker could take full control over what is presented towards the user, executing their own scripts, etc.
- Only use imported scripts from trusted third parties who you are certain take security seriously.
- Keep it updated.
- Consider importing it directly from the external provider instead of hosting it yourself. That way it can hopefully be auto-updated if any vulnerability gets publicly published. However, this would also introduce another issue, explained in the next part of this article.
The resource could change (does not apply to self-hosted scripts)
As the resource is loaded from the external source the external party is always able to change the content of the resource, and by doing so tamper with what gets executed on the site that includes the resource.
An external resource could change if the provider hosting the script gets hacked, or if they decide to go malicious and change it themselves. This introduces a single-point-of-failure situation, where an attacker could instead of hacking only you take the time and hack the hosting provider of the script and by doing so take control of all sites that include it.
It is possible to lock an external script to its current state, protecting against hacked external provider. If the script changes the inclusion will fail. This however prevents auto-updates, and can therefore be questioned if it worth including or not. See the last few paragraphs of this article for more on that https://blog.detectify.com/2016/10/27/cdns-minimize-damages-if-the-cdn-is-hacked/
For more information about subresource integrity, read Mozilla’s blog post.
Our research: How common are external resources amongst the world’s 500 most popular domains
We decided to look into how common these external resources are, and thereby also these single-point-of-failure situations. The result is the reason behind this blog post as we found it very interesting.
Our script loaded the 500 most popular domains worldwide and saved all the external resources loaded. It then extracted the domains it was loaded from, removed doublets per site and sorted it all after how common each resource was.
Technically speaking what we did here is loop through the list with domains, load each domain in a web browser using Selenium and after the page has successfully loaded extracted the src-param of each script-tag.
The results
It turns out that 40% of the most visited domains all have one domain in common:
www.google-analytics.com
Over 200 of the scanned 500 sites, include resources located there. However, as Google can be seen as trusted and not that likely to get hacked maybe we are okay with that? Looking further at the table we can see that they are also the one who clearly dominates the area with other domains as well.
However, skipping a few steps down exposes a few domains without the same reputation of security.
I am not saying that any of those fail to take security seriously, but are we really prepared to trust so big a part of the web to each and every of the players listed above? It is a question without a clear answer, but it is something that should be discussed more. Both from a security perspective, but also from a privacy point. Each of those companies are able to monitor everything you do at all the sites that include scripts from them.
As we believe there are many possible takes on this, and to drive the discussion forward, we have published the full statistic here. It contains about 1k domains that scripts are included from. The domains are those that can be found here: http://alexa.com/topsites/global
This is just scratching the surface of what would be possible to get numbers on, and feel free to take this research further. If you believe you have found anything interesting or want to discuss something related to this topic, feel free to reach out over hello[at]detectify.com!
Security tools
In addition to this, when running a scan with Detectify we highlight all external resources to help you get a better grip on the extent you use them as that sometimes can be hard to keep track of. I would guess that many times the included resources are long gone forgotten, and just going through such a list can be healthy.
