views:

881

answers:

8

I am looking for a tool that can detect malicious requests (such as obvious SQL injection gets or posts) and will immediately ban the IP address of the requester/add to a blacklist. I know, I know, the code should be able to handle such requests accordingly but there is still value in such a tool even when the site is safe from such attacks (save bandwidth, non bloated analytics, etc)

Firstly I would be looking for a cross platform (IE LAMP and .NET solution that sits at a higher level than the technology stack, perhaps at the web server or hardware level). But this might not exist and perhaps there are only technology specific solutions.
s Id like to hear your thoughts.

A: 

I am looking for something more automated. We could of course write something like this ourselves from scratch but I was thinking "this is a problem that has to have been solved before" and rather than reinvent the wheel by coding something myself, see who else has come up with a tool already.

+2  A: 

The problem with a generic tool is that it is very difficult to come up with a set of rules that will only match against a genuine attack.

SQL keywords are all English words and don't forget that the string

 DROP TABLE users;

is perfectly valid in a form field that, for example, contains an answer to a programming question.

The only sensible option is to sanitise the input before ever passing it to your database but pass it on nonetheless. Otherwise lots of perfectly normal, non-malicious users are going to get banned from your site.

Mat
+1  A: 

One method that might work for some cases would be to take the sql string that would run if you naively used the form data and pass it to some code that counts the number of statements that would actually be executed. If it is greater than the number expected, then there is a decent chance that an injection was attempted, especially for fields that are unlikely to include control characters such as username.

Something like a normal text box would be a bit harder since this method would be a lot more likely to return false positives, but this would be a start, at least.

+2  A: 

One little thing to keep in mind: In some countries (i.e. most of Europe), people do not have static IP Addresses, so blacklisting should not be forever.

Michael Stum
A: 

Now that I think about it, a Bayesian filter similar to the ones used to block spam might work decently too. If you got together a set of normal text for each field and a set of sql injections, you might be able to train it to flag injection attacks.

+6  A: 

Your almost looking at it the wrong way, no 3party tool that is not aware of your application methods/naming/data/domain is going to going to be able to perfectly protect you.

Something like SQL injection prevention is something that has to be in the code, and best written by the people that wrote the SQL, because they are the ones that will know what should/shouldnt be in those fields (unless your project has very good docs)

Your right, this all has been done before. You dont quite have to reinvent the wheel, but you do have to carve a new one because of a differences in everyone's axle diameters.

This is not a drop-in and run problem, you really do have to be familiar with what exactly SQL injection is before you can prevent it. It is a sneaky problem, so it takes equally sneaky protections.

These 2 links taught me far more then the basics on the subject to get started, and helped me better phrase my future lookups on specific questions that weren't answered.

And while this one isnt quite a 100% finder, it will "show you the light" on existing problem in your existing code, but like with webstandards, dont stop coding once you pass this test.

Uberfuzzy
+2  A: 

Oracle has got an online tutorial about SQL Injection. Even though you want a ready-made solution, this might give you some hints on how to use it better to defend yourself.

Mario Marinato -br-
A: 

One of my sites was recently hacked through SQL Injection. It added a link to a virus for every text field in the db! The fix was to add some code looking for SQL keywords. Fortunately, I've developed in ColdFiusion, so the code sits in my Application.cfm file which is run at the beginning of every webpage & it looks at all the URL variables. Wikipedia has some good links to help too.