It is. Much worse, in fact.
We ran our own test using the top 5,000 URLs from Alexa and discovered that a whopping 76.6% of them include at least one vulnerable library. If you’re curious how we conducted the test, the details are below or feel free to skip to the results.
To run the tests, we grabbed the top 5,000 URLs from Alexa. We ended up with several URLs that errored when we tried to reach them, so we kept going further down the Alexa list until we ended up with 5,000 pages that all successfully loaded.
For example, to determine the version of jQuery in use, each page would run the following code after page load:
return jQuery && jQuery.fn && jQuery.fn.jquery
We included checks for each of the following libraries in this initial run:
- jQuery UI
For each detected version, we then checked against the Snyk open-source vulnerability database to see just how many libraries had a known vulnerability.
The not-very-pretty results
jQuery is, unsurprisingly, the most popular library we tested—its incredible dominance is well documented by now. We were able to detect jQuery in 79% of the top 5,000 URLs.
Despite not being a particularly vulnerable library (there are five known vulnerabilities, each fixed in later versions), jQuery’s popularity means it makes quite a bit of mess all by itself.
As it turns out, even if we only checked for jQuery, we still end up with 75.1% of sites using a version with at least one vulnerability. This is is due in large part to just how old most of the jQuery libraries in production are. 17.4% of jQuery versions found in production are older than five years. This lines up pretty well with the initial report: people don’t update very regularly.
Further complicating the matter for jQuery users is that the only versions with no known vulnerabilities are >=3.0.0. For many current users, that’s means that updating is not as simple as adding a minor version upgrade—there are potentially breaking changes involved. Roughly 79% of jQuery libraries detected were version 1.x. Despite the fact that jQuery 3.0.0 final was released nearly a year ago, only 3.6% of sites were using any 3.x versions.
We’ll dig into jQuery in more detail in post next week, as its unparalled popularity makes it especially interesting.
jQuery UI was next in terms of popularity—found on 19.3% of the URLs tested. Once again, most jQuery UI users are using a vulnerable version despite updates being available. About 91% of jQuery UI libraries found have at least on vulnerability.
Again, much of this is due to people not updating—21.8% of sites that used jQuery UI use a version that is more than 5 years old.
Handlebars was detected on 3.4% of the URLs tested. Of those, 68% were using a vulnerable version of Handlebars.
Once again, the slow adoption of new versions is the primary culprit. On the surface, it would appear that Handlebars usage is a little more current. While the most recent version of the library (4.0.6) was not detected, the version released immediately before it (4.0.5) is also the most common one found in production, at 26.7% of Handlebars usage.
However, due to a slowed down release schedule (they’ve released only two minor versions since November of 2015) that means those sites are still using a version of the library that is nearly two years old. Over all, 40% of Handlebars versions detected were over three years old.
React, Mustache, Angular, YUI and Dojo
React (1.7%), Mustache (1.6%), Angular (1.3%), YUI (.7%) and Dojo (.2%) were detected too infrequently to draw any reliable conclusions about the use of them individually. When you look at their usage combined, vulnerable versions are still very common: 56.3% of the versions of these libraries found in the data have at least one vulnerability.
Our hopeful conclusion
The situation right now is not great, there’s no denying it. While we expected that the original number may be optimistic, we can’t say we were expecting that 77% of sites would be using at least one vulnerable library.
Because of the sensitivity of a report like this, we will not be sharing the raw data—that would essentially be handing folks a shortlist of sites and potential attack vectors. However, if you’re a website owner, you’re welcome to contact us to see if your site was in the report and, if so, whether a vulnerability was discovered. If you’re using npm packages, testing your application with Snyk may also help you to uncover potential security holes.
Continuously secure all apps with unlimited Snyk projects
April 05, 2017To do security well, you have to do it continuously, and here at Snyk we want to make that easy. That's why we changed our pricing, removing our project limit and letting you protect all your apps with a few small clicks!
Type Manipulation: Escaping Template Sandboxes
March 21, 2017This is the first of a series of posts about Type Manipulation, each demonstrating one or more real-world vulnerabilities made exploitable by manipulating types, and explaining how it could have been avoided. In this post, we'll focus on using type manipulation to circumvent template-frameworks sandboxes.
Subscribe to The Secure Developer Podcast
A podcast about security for developers, covering tools and best practices.
Interested in web security?
Subscribe to our newsletter: