most javascript vulnerabilities are because you're using it wrong.
The Frequency of Known Vulnerabilities in JavaScript
51–58 of 58 posts
Re: The Frequency of Known Vulnerabilities in JavaScript
#52In 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…
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).
Re: The Frequency of Known Vulnerabilities in JavaScript
#5337% 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.
Re: The Frequency of Known Vulnerabilities in JavaScript
#5437% 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.
Re: The Frequency of Known Vulnerabilities in JavaScript
#55Earlier quoted context omitted.
Rubysec is awesome but outdated, lacks many of the vulnerabilities in https://Snyk.io/ Also, Snyk covers JS issues, both Nodd and client side
>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…
Thank you for maintaining such a great service! You should promote your service as part of it.
Re: The Frequency of Known Vulnerabilities in JavaScript
#56Earlier quoted context omitted.
something like.. var comment = " alert(1) "; $("div.comments").append(comment); not so silly.
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 scrip…
(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 alert(1); 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 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 = "alert(1)";
$("body").append(comment);Re: The Frequency of Known Vulnerabilities in JavaScript
#57In 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…
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
Re: The Frequency of Known Vulnerabilities in JavaScript
#58Earlier quoted context omitted.
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 scrip…
(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 .…
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.