7 ms·

The Frequency of Known Vulnerabilities in JavaScript

170 points by tkadlec 10y ago

markwaldron 10y ago
For Node we use https://nodesecurity.io/ https://nodesecurity.io/ for all our npm packages. It does a pretty great job of alerting us quickly to any vulnerabilities reported for our packages.
libertymcateer 10y ago
I 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 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/ndss2017jslibs.pdf http://www.ccs.neu.edu/home/arshad/publications/ndss2017jsli...
- crowbahr 10y ago
  Doesn't seem to have a list of vulnerable sites. I imagine that there are tools out there to check against but I don't know. It doesn't seem to be a very helpful article, merely alarming.
- tkadlec 10y ago
  > * 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 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 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.
  - libertymcateer 10y ago
    Thank you kindly, dotcomrade.
- jacquesm 10y ago
  That's more than 100:1 for inclusions:websites. Ugh.
ghiculescu 10y ago
In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit 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 https://github.com/nodesecurity/nsp but keen to hear what other people are doing.
- libertymcateer 10y ago
  What do you use for CI? 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/ https://snyk.io/ This seems to be what they do. No endorsement, but this certainly seems interesting.
- bugmen0t 10y ago
  Sure, there's retire.js at https://retirejs.github.io/retire.js/ https://retirejs.github.io/retire.js/
- mistercow 10y ago
  It sounds like these Snyk folks have a CLI that can check your node modules against their database. I haven't tried it though, so all I have to go on is their feature page.
  - aviadR 10y ago
    There is also a way to test on the website, if your project is hosted
- azeirah 10y ago
  Related in nneteor land eksists this: http://www.east5th.co/blog/2015/12/07/scanning-meteor-projects-for-node-vulnerabilities/ http://www.east5th.co/blog/2015/12/07/scanning-meteor-projec....
kleiba 10y ago
Is "vuln" a word now? (Non-native speaker here, actually interested, not trying to troll.)
- godmodus 10y ago
  been a "word" since forever mate, i even remember using it in the 90s. and it's alright, you might just be young or haven't forayed much into the deeper corners of the web where 'vulns' get discussed.
  - peterwwillis 10y ago
    did you see that noobs box get pwnd by that js vuln? what a waste of a 0day. luldongues
    - godmodus 10y ago
      Well we didn't use luldongues where I hanged out, but beyond that, pretty accurate for a clean, leetspeak free version :P Ahh, it's been awhile since I was 16.
- oxide 10y ago
  it's just slang. it is not an actual word that people use in conversation, but it is an abbreviation of vulnerability used as slang among certain circles.
- klodolph 10y ago
  Yes, but it's somewhat informal and only used in writing (it sounds a bit weird if you say it out loud).
- sctb 10y ago
  We updated the submission title from “37% of sites use a JavaScript library with a known vuln–reality is probably worse” to that of the article.
jrowley 10y ago
Okay, so I hate to be that guy but if I'm only using js on the frontend what is the danger is using a library with a vulnerability?
- bastijn 10y ago
  They can for instance take over the session of your user and pretend to be them via an XSS vulnerability.
- ballenf 10y ago
  Let's imagine there was this dating service for married people... (that was backend problems, but a frontend vulnerability could have resulted in similar leakage.)
homakov 10y ago
Server side or client side? If client side, the only vuln that matters is (DOM) XSS, is it the case? If not, that's not worth patching.
scandox 10y ago
I'd like to see some practical examples of exploited vulnerabilities in client side JS libraries. I always think of everything client side as happening in a context of total insecurity- in the sense that I make no assumptions of what the client will do in relation to the server. Is this more about libraries that expose the client to attacks from code on other sites? Perhaps I'm complacent about this but I often think of this as the responsibility of the browser...
- mi100hael 10y ago
  Ever heard of XSS?
  - scandox 10y ago
    Yes but what I think I had not given enough thought to were DOM-based vulnerabilities, which it seems to me are the ones that would be relevant to 3rd party JS libs. Anyway I will certainly be giving this deeper thought.
    - steveax 10y ago
      If you're for instance relying on handlebars to escape displayed content from user input properly and your version has a vulnerability...
- Rapzid 10y ago
  Your users aren't authorized to carry out actions on the server? There is no information in your front end that should remain secret to you and the user?
  - scandox 10y ago
    Indeed there is. Most often a token, stored in localStorage. But that token can be used from anywhere and with any mechanism. So I guess what I mean is that if there is a way for somebody to intercept or retrieve it, then I have in the past viewed that as a vulnerability of the browser (probably wrongly). So what I'd love to understand better is the kind of attacks that would be practical, and how they would exploit a 3rd party library. By the way I am totally receptive to the possibility that there may be grave vulnerabilities. I just don't have the kind of mind that easily thinks of them. Edited: for clarity
rattray 10y ago
mods: can the title be changed to clarify that these are vulnerabilities in "JavaScript Libraries", not JavaScript itself?
heroprotagonist 10y ago
Does 398 vulnerabilities in NPM seem low? https://snyk.io/vuln?type=npm https://snyk.io/vuln?type=npm
- edejong 10y ago
  Although it seems pedantic, it is important to note that these are 398 publicly known vulnerabilities. An easily overlooked distinction. (Small edit due to style).
chiliap2 10y ago
The article lists https://snyk.io/vuln/npm:moment:20161019 https://snyk.io/vuln/npm:moment:20161019 as an example of a vulnerability (although not one that is tracked). Could someone explain how a Javascript vulnerability could cause a DDoS? Even if it does cause Moment to hang, how would that affect the server?
- tmikaeld 10y ago
  A simple Ajax loop would certainly stress the server when run on a lot of clients.
jlebrech 10y ago
most javascript vulnerabilities are because you're using it wrong.
sytelus 10y ago
37% of surveyed sites used at least one library with known vulnerability. Websites don't upgrades these libraries frequently either. The question in my mind is why browsers don't ship with popular JS libraries? That way downloads can be reduced and also such security issues can be addressed more centrally.
- Walf 10y ago
  It doesn't matter how the updates to libraries are done, people don't update because it means API changes and testing your code to see what broke and fix it. Most clients do not understand, let alone want to pay for that kind of maintenance.

170 points by tkadlec 10y ago

For Node we use https://nodesecurity.io/ https://nodesecurity.io/ for all our npm packages. It does a pretty great job of alerting us quickly to any vulnerabilities reported for our packages.

libertymcateer 10y ago

I 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 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/ndss2017jslibs.pdf http://www.ccs.neu.edu/home/arshad/publications/ndss2017jsli...

crowbahr 10y ago
Doesn't seem to have a list of vulnerable sites. I imagine that there are tools out there to check against but I don't know. It doesn't seem to be a very helpful article, merely alarming.
tkadlec 10y ago
> * 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 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 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.
- libertymcateer 10y ago
  Thank you kindly, dotcomrade.
jacquesm 10y ago
That's more than 100:1 for inclusions:websites. Ugh.

ghiculescu 10y ago

In ruby land, there's a great gem - https://github.com/rubysec/bundler-audit 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 https://github.com/nodesecurity/nsp but keen to hear what other people are doing.

libertymcateer 10y ago
What do you use for CI? 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/ https://snyk.io/ This seems to be what they do. No endorsement, but this certainly seems interesting.
bugmen0t 10y ago
Sure, there's retire.js at https://retirejs.github.io/retire.js/ https://retirejs.github.io/retire.js/
mistercow 10y ago
It sounds like these Snyk folks have a CLI that can check your node modules against their database. I haven't tried it though, so all I have to go on is their feature page.
- aviadR 10y ago
  There is also a way to test on the website, if your project is hosted
azeirah 10y ago
Related in nneteor land eksists this: http://www.east5th.co/blog/2015/12/07/scanning-meteor-projects-for-node-vulnerabilities/ http://www.east5th.co/blog/2015/12/07/scanning-meteor-projec....

kleiba 10y ago

Is "vuln" a word now? (Non-native speaker here, actually interested, not trying to troll.)

godmodus 10y ago
been a "word" since forever mate, i even remember using it in the 90s. and it's alright, you might just be young or haven't forayed much into the deeper corners of the web where 'vulns' get discussed.
- peterwwillis 10y ago
  did you see that noobs box get pwnd by that js vuln? what a waste of a 0day. luldongues
  - godmodus 10y ago
    Well we didn't use luldongues where I hanged out, but beyond that, pretty accurate for a clean, leetspeak free version :P Ahh, it's been awhile since I was 16.
oxide 10y ago
it's just slang. it is not an actual word that people use in conversation, but it is an abbreviation of vulnerability used as slang among certain circles.
klodolph 10y ago
Yes, but it's somewhat informal and only used in writing (it sounds a bit weird if you say it out loud).
sctb 10y ago
We updated the submission title from “37% of sites use a JavaScript library with a known vuln–reality is probably worse” to that of the article.

jrowley 10y ago

Okay, so I hate to be that guy but if I'm only using js on the frontend what is the danger is using a library with a vulnerability?

bastijn 10y ago
They can for instance take over the session of your user and pretend to be them via an XSS vulnerability.
ballenf 10y ago
Let's imagine there was this dating service for married people... (that was backend problems, but a frontend vulnerability could have resulted in similar leakage.)

homakov 10y ago

Server side or client side? If client side, the only vuln that matters is (DOM) XSS, is it the case? If not, that's not worth patching.

scandox 10y ago

I'd like to see some practical examples of exploited vulnerabilities in client side JS libraries. I always think of everything client side as happening in a context of total insecurity- in the sense that I make no assumptions of what the client will do in relation to the server. Is this more about libraries that expose the client to attacks from code on other sites? Perhaps I'm complacent about this but I often think of this as the responsibility of the browser...

mi100hael 10y ago
Ever heard of XSS?
- scandox 10y ago
  Yes but what I think I had not given enough thought to were DOM-based vulnerabilities, which it seems to me are the ones that would be relevant to 3rd party JS libs. Anyway I will certainly be giving this deeper thought.
  - steveax 10y ago
    If you're for instance relying on handlebars to escape displayed content from user input properly and your version has a vulnerability...
Rapzid 10y ago
Your users aren't authorized to carry out actions on the server? There is no information in your front end that should remain secret to you and the user?
- scandox 10y ago
  Indeed there is. Most often a token, stored in localStorage. But that token can be used from anywhere and with any mechanism. So I guess what I mean is that if there is a way for somebody to intercept or retrieve it, then I have in the past viewed that as a vulnerability of the browser (probably wrongly). So what I'd love to understand better is the kind of attacks that would be practical, and how they would exploit a 3rd party library. By the way I am totally receptive to the possibility that there may be grave vulnerabilities. I just don't have the kind of mind that easily thinks of them. Edited: for clarity

rattray 10y ago

mods: can the title be changed to clarify that these are vulnerabilities in "JavaScript Libraries", not JavaScript itself?

heroprotagonist 10y ago

Does 398 vulnerabilities in NPM seem low? https://snyk.io/vuln?type=npm https://snyk.io/vuln?type=npm

edejong 10y ago
Although it seems pedantic, it is important to note that these are 398 publicly known vulnerabilities. An easily overlooked distinction. (Small edit due to style).

chiliap2 10y ago

The article lists https://snyk.io/vuln/npm:moment:20161019 https://snyk.io/vuln/npm:moment:20161019 as an example of a vulnerability (although not one that is tracked). Could someone explain how a Javascript vulnerability could cause a DDoS? Even if it does cause Moment to hang, how would that affect the server?

tmikaeld 10y ago
A simple Ajax loop would certainly stress the server when run on a lot of clients.

jlebrech 10y ago

most javascript vulnerabilities are because you're using it wrong.

sytelus 10y ago

37% of surveyed sites used at least one library with known vulnerability. Websites don't upgrades these libraries frequently either. The question in my mind is why browsers don't ship with popular JS libraries? That way downloads can be reduced and also such security issues can be addressed more centrally.

Walf 10y ago
It doesn't matter how the updates to libraries are done, people don't update because it means API changes and testing your code to see what broke and fix it. Most clients do not understand, let alone want to pay for that kind of maintenance.