from Hacker News

The Frequency of Known Vulnerabilities in JavaScript

by tkadlec on 3/9/17, 6:54 PM with 57 comments

• by ghiculescu on 3/9/17, 7:36 PM

  In 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 other people are doing.

• by scandox on 3/9/17, 8:10 PM

  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...

• by markwaldron on 3/9/17, 8:57 PM

  For Node we use 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.

• by libertymcateer on 3/9/17, 7:34 PM

  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/ndss2017jsli...

• by homakov on 3/9/17, 8:07 PM

  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.

• by rattray on 3/9/17, 9:28 PM

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

• by heroprotagonist on 3/9/17, 10:14 PM

  Does 398 vulnerabilities in NPM seem low?

  https://snyk.io/vuln?type=npm

• by chiliap2 on 3/10/17, 3:02 AM

  The article lists 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?

• by jrowley on 3/9/17, 8:06 PM

  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?

• by sytelus on 3/10/17, 12:22 PM

  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.

• by jlebrech on 3/10/17, 9:11 AM

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

• by kleiba on 3/9/17, 7:57 PM

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