Live data from Hacker News

The Frequency of Known Vulnerabilities in JavaScript

snyk.io

31–40 of 58 posts

Re: The Frequency of Known Vulnerabilities in JavaScript

#31
post #16

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…

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

I'd recommend safety for Python.

https://github.com/pyupio/safety

Re: The Frequency of Known Vulnerabilities in JavaScript

#32
post #11

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…

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 but don't contribute back.

Re: The Frequency of Known Vulnerabilities in JavaScript

#33

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 samp…

That's more than 100:1 for inclusions:websites. Ugh.

Re: The Frequency of Known Vulnerabilities in JavaScript

#34
post #26

Earlier quoted context omitted.

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…

https://en.wikipedia.org/wiki/Cross-site_scripting is a big one.

But I don't think jQuery vulnerabilities could possibly open you up to XSS attacks unless you were already doing something silly.

Re: The Frequency of Known Vulnerabilities in JavaScript

#35
post #15

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?

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

Re: The Frequency of Known Vulnerabilities in JavaScript

#36
post #19

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…

Ever heard of XSS?

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.

Re: The Frequency of Known Vulnerabilities in JavaScript

#37
post #26
post #23

Earlier quoted context omitted.

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…

Your humility is pretty awesome.

As a simple example, paste alert("haha") 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 , 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..

    404
    

Sorry, /x/y/z doesn't exist.

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

https://yoursite.com/this-is-a-long-url-thats-hidden-in-a-an...

Re: The Frequency of Known Vulnerabilities in JavaScript

#38
post #34

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Cross-site_scripting is a big one.

But I don't think jQuery vulnerabilities could possibly open you up to XSS attacks unless you were already doing something silly.

something like..

    var comment = "alert(1)";
    $("div.comments").append(comment);
not so silly.

Re: The Frequency of Known Vulnerabilities in JavaScript

#40
post #34

Earlier quoted context omitted.

But I don't think jQuery vulnerabilities could possibly open you up to XSS attacks unless you were already doing something silly.

something like.. var comment = " alert(1) "; $("div.comments").append(comment); not so silly.

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?
Post reply on HN