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

Eventually I found a little gem that seemed to work:

1
2
3
4
5
6
7
8
9

EXEC SP_ADDLINKEDSERVER 'EXCEL2',
	'Excel',
	'Microsoft.Jet.OLEDB.4.0',
	'D:\data.xls',
	NULL,
	'Excel 8.0',
	NULL
 
SELECT * FROM excel2...a$ WHERE [Whatever COLUMN] IS null

Effectively you alias the excel document as a linked sql server (in this example, excel2). You only have to do this once. Once it’s setup it works until you de-link the server alias (or you move the data source)

This helped me tremendously in getting data and querying it with T-SQL without having to import it like I’m used to with DTS. You might want to be on the look-out for language differences between the two, but a simple COLLATE DATABASE DEFAULT should do the trick in most instances when inner join’ing or comparing two different server data.