21–30 of 36 posts
I love the idea, but I think the fighting-back tricks are a bit disappointing. I expected stuff like "uses its own botnet to ddos the attacker". Yeah yeah, stupid, not realistic. But redirecting to goatse? Come on. That's less exciting than a garfield comic.
Entire project was created in a matter of hours so it's pretty basic for now. Not a fan of the "this is lame shitsux" mentality going around but I'll get used to it. All included modules will become much more sophisticated with time so please hold those comments off until I get more than 2 hours to put towards the project
If you have any detection/payload suggestions please comment in here and I will most likely add them. Keep in mind that this is all for the lulz
If you have anything you want to add, feel free to fork!
Completely misses the point of XSS and XSRF attacks. In those scenarios the 'attacking' browser is actually the attacker's victim. If you use this module, an attacker can link a victim to you and have your 'defences' arbitrarily attack them, making you part of the problem, not the solution.
If you want to prevent this from happening there will be http-xss and socket-xss detectives in the future, just leave out the http-xss to keep it safe. Optionally you could always set your payloads to logging only
1. Detecting XSS by looking for '', '(', or ')' in the URL is a very naive approach. It can be bypassed fairly easily and many XSS vectors could have payloads constructed that bypass this filter. Also, you're likely to get some false positives for a certain subset of applications, since parenthesis have legitimate uses.
2. I'm not sure on what basis the first part of the CSRF protection is valid or what it's trying to protect. Is it looking for an Accept header for application/json?
3. The second part of the CSRF protection, which looks at the referer header, seems buggy and easy to bypass. What is it trying to accomplish? Right now, it seems like it blocks POST requests where the referer is set and contains the server's hostname (which valid requests will have).
4. Detecting CSRF by looking for non-GET/POST methods is a bad idea unless your application specifically constrains itself to those two methods. Many modern applications are using PUT and DELETE internally for routing purposes.
5. Detecting LFI in the URL by looking for ../ is, again, naive (although less likely to lead to false positives than the XSS testing).
6. The most "objectionable" part here seems to be the "fight back" options. There are definitely some legitimate concerns about an attacker being able to get a targeted user banned from a site (after all, you can't distinguish between a failed CSRF that an attacker is sending and a failed CSRF that an attacker tried to convince a target to send). For the most part though, I don't think they're a big deal for a small, independent site that opts-in to them: they sound a lot like the Miserable Users mod for VB (http://www.vbulletin.org/forum/showthread.php?t=93258)
That being said, no system that operates like a WAF is going to be perfect. The idea of a mod_security-like system for node.js is very cool though. I just think the way you tried to launch it here, with no indication on GitHub or otherwise that it's not a finished product, has led to some backlash. :-)
yes, i know that it doesn't "really" "attack back" but when you phrase it that way you're going to raise some hackles.
Not to belabor the point, since other people have assessed this library quite well, but: 1. Detecting XSS by looking for ' ', '(', or ')' in the URL is a very naive approach. It can be bypassed fairly easily and many XSS vectors could have payloads constructed that bypass this filter. Also, you're likely to get some false positives for a certain subset of applications, since parenthesis have legitimate uses. 2. I'm n…
As I said to someone in another comment, the main purpose of the framework is socket.io packet analysis. The http detectives are merely for testing at this point while the framework itself matures
OP/Creator here Entire project was created in a matter of hours so it's pretty basic for now. Not a fan of the "this is lame shitsux" mentality going around but I'll get used to it. All included modules will become much more sophisticated with time so please hold those comments off until I get more than 2 hours to put towards the project If you have any detection/payload suggestions please comment in here and I will…
OP/Creator here Entire project was created in a matter of hours so it's pretty basic for now. Not a fan of the "this is lame shitsux" mentality going around but I'll get used to it. All included modules will become much more sophisticated with time so please hold those comments off until I get more than 2 hours to put towards the project If you have any detection/payload suggestions please comment in here and I will…
Good luck though!
OP/Creator here Entire project was created in a matter of hours so it's pretty basic for now. Not a fan of the "this is lame shitsux" mentality going around but I'll get used to it. All included modules will become much more sophisticated with time so please hold those comments off until I get more than 2 hours to put towards the project If you have any detection/payload suggestions please comment in here and I will…
I think what's important to take away here is that people are genuinely interested in some sort of NodeJS web security framework given by the fact that people are viewing your source and commenting at all. If we thought it was a bad idea, I don't think you would have gotten any feedback at all. So, I think if you sift through the noise, you'll find a few folks will put up some good suggestions.