The idea of a firewall of some sort for web applications seems like a good idea, but this particular one seems rather lame. For example, here's the complete code that implements the 'local file inclusion' attack detection:
var url = require('url');
exports.check = function (req, res) {
if (req.url.indexOf('../') > -1) {
fusker.handleAttack('LFI', req, res);
}
};
That's very simplistic and I wouldn't be surprised if you could get round it with trickery like ..%2F or similar encodings since if you dig in it's being passed the req from the http Node.js module and using the .url parameter. That returns the full URL from the request itself.
Also, the whole 'fight back' idea is a bad one. We've seen from the spam world that fighting back tends to create collateral damage. If someone is attacking your web site then it's best just to silently discard attacks, after all if an attack back is detected that gives the attacker information.
Also, blacklisting IP addresses on the Internet is quite a dangerous thing to do. The IP address being presented to the end web site may well come from a company or from an ISP where there are many, many legitimate users on the same IP. A blacklist needs to be managed carefully to avoid an attacker knocking out a large group of legitimate users.
My guess is this is just a proof of concept.
For this kind of thing, [Snort](http://www.snort.org/) with it's huge corpus of intrusion detection patterns.
It "attacks back" in this case by redirecting users to various other sites. The fun thing about applications like this one is that they make for a great self-inflicting DoS; all I have to do, as an attacker, is run a script that launches lame attacks with spoofed IPs against a fusker site. With not too much trouble, I could cause your website to redirect a lot of your U.S. customers to goatse, or whatever module you decide to use.
Hate to be a killjoy, but things like this are usually not a good idea. Unfortunately, somebody has to rediscover that every six months or so.
edit: nevermind, I was going off of hilariously out-of-date information. TCP ISNs haven't been easy to predict in -- gulp -- about a decade. Damn, now I feel old.
You'd have to have a high level of control of the network that the server lives on in order to do this sort of spoofing of tcp connections for arbitrary IP addresses.
And if you had that level of control anyway, you wouldn't need to spoof attacks against the server, you could just redirect all incoming requests to a different server which returns whatever HTTP response headers or bodies that you want.
So your described attack is highly unlikely to ever happen.
Fair enough, 'attacking back' might be a bit of overkill, but you can't deny the utility of a pluggable module that spots possible attacks (as connectjs middleware, for instance). What I got out of this is a simple way to implement some form of protection on my site.
You spoof the IP address you are sending from and then predict the TCP sequence number so you can make it look as though you are receiving the replies (even though they are going to another machine since you spoofed the IP address).
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!
Well, it would help if a link were posted when the project is in a more mature state. When something is linked and upvoted, people will judge it by the current quality, not some future state of the project.
I think the idea is fun, but the HN community has pretty high expectations. Half-implemented ideas out as a solution attracts plenty of critics.
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.
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.
Hmm... this never occurred to me. The future of the project is going to be socket.io packet analysis with detectives. The current http request analysis is really weak and not intended to be the main focus
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
If it's not intended to be the main focus, why are you bothering to demo it now? Why not wait and show us something even slightly representative of what your project is supposed to be like?
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.
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. :-)
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
At the very least it should be using the asyncness of node to hold malicious connections open forever, bogging down any synchronous attack tools. Although, I doubt there are any such attack tools out there these days.
It's all fun and games to imagine attackers and script kiddies having trouble with this. But its scary to think what might happen if one the innocent visitors/customers are marked as attackers by mistake.
"Attacking back" with shock images may be genuinely legally problematic, given the untested new Tennessee law on the subject. http://arstechnica.com/tech-policy/news/2011/06/tenn-law-ban... . Using the included nimp payload is even more legally problematic since it actually does redirect the user to a site that contains malicious code.
I think this project, much like all "offensive security" projects, is fundamentally misguided. At best, this project loudly alerts the hacker every time an attack is detected, providing an easy way to black-box test the service's attack detection criteria. At worst, it provides an easy way for jerks to goatse, Last Measure, etc. third parties using the webmaster's site. While I understand the kind of spiteful thrill that would come from redirecting a (maybe not) attacker to a shocking image, quietly stopping and logging the attack is always the best option.
The solution to this is not to launch a counter attack on the attacker, but to automatically launch automated collaborative investigation where evidence is gathered to try to nudge the attacker into doing something that reveals his location/identity.
1. Software notices inappropriate behavior.
2. Launches a honeypot service with lots of holes in it to give attacker opportunity to get root.
3. Root takes them to a locked down part of the computer.
4. Have the system project a computer where the admins are complete fools, making the attackers feel a false sense of security.
5. Send investigation information about the attacker to other servers running this software, ask other servers to "Help me find the bozo using this spoofed IP address". If you see someone transmitting on this IP, help me find its true origin.
The software could recursively trace right back to the ISP that is hosting the computer of the attacker. Don't have it launch a counter attack, the goal here is not to send the attacker to goatse (he probably enjoys it). The counterattack should be in the form of a policeman tapping the attacker on the shoulder and saying: "you have the right to remain silent".
The answer is not fighting back immediately, it's sun tzu's legendary advice, let the enemy think they have gamed your box, so they launch a bolder move, then you catch them with their hand in the cookie jar.
How exactly is this "recursive trace" going to work? As soon as you get to a computer the attacker controls he can subvert whatever mechanism you're thinking of.
If you were clever with virtualization software, you could let the VM guest get taken over, and use heuristics on the host to detect where they were coming from.
That's very simplistic and I wouldn't be surprised if you could get round it with trickery like ..%2F or similar encodings since if you dig in it's being passed the req from the http Node.js module and using the .url parameter. That returns the full URL from the request itself.
And check out how SQL injection is detected: https://github.com/wearefractal/fusker/blob/master/lib/detec... It appears to be completely unimplemented.
Also, the whole 'fight back' idea is a bad one. We've seen from the spam world that fighting back tends to create collateral damage. If someone is attacking your web site then it's best just to silently discard attacks, after all if an attack back is detected that gives the attacker information.
Also, blacklisting IP addresses on the Internet is quite a dangerous thing to do. The IP address being presented to the end web site may well come from a company or from an ISP where there are many, many legitimate users on the same IP. A blacklist needs to be managed carefully to avoid an attacker knocking out a large group of legitimate users.