dataguy - 4:55 pm on May 28, 2008 (gmt 0)

There sure is a lot of misinformation being passed around about this exploit over the net. Maybe for the purposes of this thread we should decide if we are talking about sql injection attacks in general or this specific "nihaorr1.com" attack. This specific attack is targeting classic asp pages which connect to an MS SQL Server database. Giving information about how to prevent sql injections into a php page has very little to do with preventing this attack.

I should also point out that it doesn't help anyone to wrinkle up your nose and scoff at those who don't have 100% perfect code. Many of our web sites have been written before anyone in the world had dreamed up such exploits, when 'best practices' didn't include protection against these attacks. My sites have at least 4 layers of protection that as far as I can tell, will protect them against this attack, but still I was still up all night last night checking my sites for vulnerabilities. Even the phd's at Google apparently have problems knowing when to escape special characters as it is common to come across the text "don/'t" on their instructional pages.

The best source I've found for good information about this particular attack is at [forums.iis.net...]

A brief overview of what is discussed there:

* This attack starts with the attacking bot finding pages ending in .asp in Google.
* While the SQL injection method is common, the command is pretty advanced, iterating through every table and every field in each table, trying to appending the javascript code which then appears in the web sites pages and attempts to load several virus-laden pages through the web surfers browser.
* It appears that the injection appears in the querystring, so evidence of an attack attempt can be seen in standard server log files.
* Standard protection against SQL injection does work (I won't repeat them here), though there are some reports of infected databases through stored procedures, which I've never heard of before.

A few new ideas on protection against this attack are:
* Denying "SELECT" on the syscolumns and sysobjects system tables. This will prevent the bot from iterating through each table and field. Permission to do a SELECT on these system tables are given by default on SQL Server, though it is rare that any site would need this.
* There are a few suggestions for running an include file at the beginning of each asp page which loops through all request and server variables and checks for the phrase "DECLARE". If this phrase is found, it transfers to a different blank or possibly static page. You could also search for a few other common query phrases like EXEC, INSERT, DELETE, ;--, ';, varchar, syscolumns, etc. This seems to be a good quick and dirty way to protect a site against SQL injection attack until the holes are fixed properly.

I hope this all makes sense, I haven't had much sleep lately ;)