5 msΒ·
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 con
by scandox 10y ago
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...
- mi100hael 10y agoEver heard of XSS?
- scandox 10y agoYes 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.
- steveax 10y agoIf you're for instance relying on handlebars to escape displayed content from user input properly and your version has a vulnerability...
- Rapzid 10y agoYour 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 10y agoIndeed 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
- olalonde 10y agohttps://en.wikipedia.org/wiki/Cross-site_scripting https://en.wikipedia.org/wiki/Cross-site_scripting is a big one.
- ng12 10y agoBut I don't think jQuery vulnerabilities could possibly open you up to XSS attacks unless you were already doing something silly.
- jamiesonbecker 10y agosomething like.. var comment = "<script>alert(1)</script>"; $("div.comments").append(comment); not so silly.
- ng12 10y agoIt 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?
- AgentME 10y agoI 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).
- et-al 10y agoThis 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?