21–30 of 58 posts
Is "vuln" a word now? (Non-native speaker here, actually interested, not trying to troll.)
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.
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…
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…
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?
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…
Add it to your composer.json and it will simply conflict with all lib versions with known vulnerabilities.
The data source used (https://github.com/FriendsOfPHP/security-advisories) has an excellent history of keeping up-to-date.
Disclosure: I'm the founder of Roave.
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…
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?
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
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…
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…