How to find + stop SQL injection attacks

There’s a lot of stuff out there about SQL injection attacks, but there’s not much that will help you figure out how to stop these attacks from occurring.

First, let’s talk about what a SQL Injection Attack really is. Some people think it’s a virus of sorts, that is “inside your site.” Not the case. These are bot attacks by other virus infected computers. They simply use a brute force approach of scanning URLs that take POST/GET inputs and attempt to send their own data to them.

So, how do you track these down and stop them? For web sites powered by Microsoft’s IIS, here are our suggestions:

1. Look at your IIS logs
   Try searching for the word “DECLARE” or “EXECUTE.” If you’ve been hit by an attack, these will more than likely show up in your IIS logs — at least for any attack that was attempted using “GET” posts. If you do find any instances of “DECLARE” or “EXECUTE” these are the pages to start with.
2. Use centralized database connection handling
   Simple, make a centralized file (e.g. connection.asp if you are using ASP) that handles all of your DB access. This way, it’s easier to make sure that you are SQL encoding your pages. You can easily search queries for “DECLARE” and “EXECUTE” and stop the attacks dead in their tracks.
3. Implement a site wide solution
   If you are running your own server, we highly recommend ISAPI_Rewrite from HeliconTech (http://www.helicontech.com/isapi_rewrite). This is an ISAPI filter that allows you to do a variety of things, including scan URL data. This will stop 99% of attacks without changing ANY code on your site!\
4. Never use “sa” as your database user, create a user for the database you’re working from and then remove privileges to read the master dbo. This prevents the attacker from “sniffing” your database structure, however, these attacks have evolved so that sanitized stored procedure based attacks happen even with these types of security in place. See http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf for more information on this and other ideas in preventing SQL Injection attacks.

If you’ve ever been scratching your head wondering where the leak in your programming is (or have taken over a project from someone else) then the best way to determine through which page the attack happened is by checking out the IIS logs.

There are many scripts available to clean up, but the best tip is to backup hourly, and to follow best practices (some of which I highlighted here). Good luck