The Frequency of Known Vulnerabilities in JavaScript
1–10 of 58 posts
Re: The Frequency of Known Vulnerabilities in JavaScript
#2* Based on the below text (taken from the underlying paper[0]) can you fine folks spot check me on my re-interpretation of the central claim?
>Using these tools, we crawled the Alexa Top 75 k websites and a random sample of 75 k websites drawn from a snapshot of the .com zone in May 2016. These two crawls allow us to compare and contrast JavaScript library usage between popular and unpopular websites. In total, we observed 11,141,726 inline scripts and script file inclusions; 87.7 % of Alexa sites and 46.5 % of .com sites used at least one well-known JavaScript library, with jQuery being the most popular by a large majority. Analysis of our dataset reveals many concerning facts about JavaScript library management on today’s Web. More than a third of the websites in our Alexa crawl include at least one vulnerable library version, and nearly 10 % include two or more different vulnerable versions. From a per-library perspective, at least 36.7 % of jQuery, 40.1 % of Angular, 86.6 % of Handlebars, and 87.3 % of YUI inclusions use a vulnerable version.
* My reinterpretation: So, of the top 75k Alexa website, 37% use a version of one of the 72 tested javascript libraries with that has a "known vulnerability"?
Is that the claim?
* Can anyone get a table of the 72 libraries tested and an associated matrix of the known vulnerabilities?
* Are there different levels of classification in these vulnerabilities? As in, do some allow for successful MITM, do some allow for injected code, or are they more benign? Are we to assume that they are all very serious vulnerabilities? Are we to assume that all these are browser-security vulnerabilities, or are they susceptible to attack from other network sources?
This is very interesting, but I think we need a lot more data. Frankly, I am a bit disappointed that they do not have a simple to read table of the most popular 72 libraries and their known vulnerable packages - I would love to know if for no other reason to check that I am not using any of them.
Though I will say one thing: 37% is a lot lower than I would have anticipated but a still very sobering number.
[0] http://www.ccs.neu.edu/home/arshad/publications/ndss2017jsli...
Re: The Frequency of Known Vulnerabilities in JavaScript
#3We run it as part of our CI. When a vulnerability drops, it gets fixed pretty quickly since otherwise everyone's build fails.
Does anyone know of any equivalents for the JS world? A quick google finds https://github.com/nodesecurity/nsp but keen to hear what other people are doing.
Re: The Frequency of Known Vulnerabilities in JavaScript
#4I just looked at the paper, very briefly. Below is kind of a tl;dr (please do not hestitate to correct me if I got anything wrong [though that particular statement goes without saying on this site...]) * Based on the below text (taken from the underlying paper[0]) can you fine folks spot check me on my re-interpretation of the central claim? >Using these tools, we crawled the Alexa Top 75 k websites and a random samp…
Re: The Frequency of Known Vulnerabilities in JavaScript
#5In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit - that lets you know when specific gem versions have a known security vulnerability. We run it as part of our CI. When a vulnerability drops, it gets fixed pretty quickly since otherwise everyone's build fails. Does anyone know of any equivalents for the JS world? A quick google finds https://github.com/nodesecurity/nsp but keen to hear what…
And yes, that is a great question. I would love to know. I guess, however, the follow-up question is how current the audit package is kept. It seems like this is the sort of thing that would need -constant- update in order to be useful. However, as is often the case, please do correct me if I am wrong.
Edit: one of the folks from Snyk responded to me below: https://snyk.io/ This seems to be what they do. No endorsement, but this certainly seems interesting.
Re: The Frequency of Known Vulnerabilities in JavaScript
#6I just looked at the paper, very briefly. Below is kind of a tl;dr (please do not hestitate to correct me if I got anything wrong [though that particular statement goes without saying on this site...]) * Based on the below text (taken from the underlying paper[0]) can you fine folks spot check me on my re-interpretation of the central claim? >Using these tools, we crawled the Alexa Top 75 k websites and a random samp…
Me either. They list out the 30 most popular of those 72, but I can't see the full list. Yet another reason why the 37% they report may be underselling the issue—without being able to see the full list, it's hard to confirm 100%.
> To summarize (please correct me if I am wrong): So, of the top 75k Alexa website, 37% use a version of one of the 72 tested javascript libraries with a known vulnerability?
Yes, that's the claim they're making.
> Are there different levels of classification in the vulnerabilities? As in, do some allow for successful MITM, do some allow for injected code, or are they more benign?
They don't go into that. Based on what I know about the vulns in the libraries they discuss, they didn't do anything to distinguish low/medium/high or vulnerability type. From what we see in our DB, XSS remains the most common type.
> This is very interesting, but I think we need a lot more data
I'm digging through our (https://snyk.io) analytics and a few other sources to try to get a different (albeit, npm-centric) perspective on this. I'll try to remember to come back and ping you when it's done.
Re: The Frequency of Known Vulnerabilities in JavaScript
#7In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit - that lets you know when specific gem versions have a known security vulnerability. We run it as part of our CI. When a vulnerability drops, it gets fixed pretty quickly since otherwise everyone's build fails. Does anyone know of any equivalents for the JS world? A quick google finds https://github.com/nodesecurity/nsp but keen to hear what…
Re: The Frequency of Known Vulnerabilities in JavaScript
#8I just looked at the paper, very briefly. Below is kind of a tl;dr (please do not hestitate to correct me if I got anything wrong [though that particular statement goes without saying on this site...]) * Based on the below text (taken from the underlying paper[0]) can you fine folks spot check me on my re-interpretation of the central claim? >Using these tools, we crawled the Alexa Top 75 k websites and a random samp…
> * The complete list of the 72 libraries that were tested? I could not find it. Me either. They list out the 30 most popular of those 72, but I can't see the full list. Yet another reason why the 37% they report may be underselling the issue—without being able to see the full list, it's hard to confirm 100%. > To summarize (please correct me if I am wrong): So, of the top 75k Alexa website, 37% use a version of one…
Re: The Frequency of Known Vulnerabilities in JavaScript
#9In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit - that lets you know when specific gem versions have a known security vulnerability. We run it as part of our CI. When a vulnerability drops, it gets fixed pretty quickly since otherwise everyone's build fails. Does anyone know of any equivalents for the JS world? A quick google finds https://github.com/nodesecurity/nsp but keen to hear what…
Re: The Frequency of Known Vulnerabilities in JavaScript
#10In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit - that lets you know when specific gem versions have a known security vulnerability. We run it as part of our CI. When a vulnerability drops, it gets fixed pretty quickly since otherwise everyone's build fails. Does anyone know of any equivalents for the JS world? A quick google finds https://github.com/nodesecurity/nsp but keen to hear what…