[nbpoole]

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

[mikaelchoni]

Thanks for the suggestions. All of the detections are extremely primitive right now, I didn't get a lot of time to put work into them (the whole project has roughly 2-3 hours of time into it) but tomorrow they will be improved.

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