SQL Injection Attacks - how to deal with them

August 16th, 2008


It's not like SQL injection attacks are new.

They go back to at least late 2004, when they appeared in Europe and Asia.  A German TV station was attacked, then a Taiwanese security magazine.  In 2006, Russian hackers broker into a Rhode Island government website and stole credit card data.

The attacks were proliferating.  In 2007, a hacker defaced the Microsoft UK web site.  Later on that year, the UN website was defaced with a SQL injunction attack.  Have they no shame?

In January 2008, tens of thousands of PC websites were defaced by automated SQL injection attacks that exploited the vulnerability of Microsoft SQL server.

In April 2008, the social security numbers of the sex offenders on the Sexual Offender Registry of Oklahoma were stolen by an injection attack.

In May 2008, a server farm in China used automated queries to Google's search engine to identify SQL server websites that were vulnerable.

In July 2008, the Malaysian site for Kaspersky, a Russian computer security company, was hacked using a SQL injection.

From April 2008 to the present, there have been increasing SQL injection attacks exploiting the SQL injection vulnerability of Microsoft Internet Information Services and SQL server.


These attacks don't require the hacker to have access to the server or, for that matter, the names of database fields.  The attack is on all text fields in all tables with a single hacked SQL request.  The attack attaches an html string to each field that activates a malware javascript file called from a remote location.  When that value is later displayed to a user of the hacked site, the script tries to gain control over the user’s system.

The number of exploited web pages is estimated at 500,000 so far, and growing daily.  These attacks are across the board, against government sites and well as commercial sites, and against open source SQL as well as Microsoft SQL.  The attacking mechanisms can be manual or by automated spiders or by modified versions of popular software such as QuickTime and RealPlayer.

SQL is a rich and complex language, so there are many techniques by which the attack can be accomplished.  The common approach is for the hacker to modify a variable being passed from the user’s browser URL address line or from a form on the browser to a SQL search string which is being processed on the website.

With this approach, hackers or their automated spiders can inject draconian instructions into the SQL commands written for the site, and these can do any number of awful things, like stealing all the data from the SQL database, destroying the database altogether or modifying the records by adding references to remote malware that spreads the attack through innocent visitors using the site, in a kind of Trojan horse virus.


Don’t think you’re somehow exempt.  If you’re using SQL in any form you're vulnerable.  Most websites are data driven these days, and most of those use SQL in one form or another.  The hackers and their spiders may very well visit an attack on your site any time.

It goes without saying you need to back up your SQL database, all of it, every day and keep those backups for perhaps a longer period of time than before.  If you have 10 days of backup but you don’t watch your site and 10 days go by, you won’t have a useable backup and you’ll be SOL.

How do you know you’ve been attacked?  Well, the data on your screen is truncated and you get strange characters like hanging apostrophes and angle brackets on your screen where database information ought to be.  Sometimes you get wise guy jokes there too.  Don't click on what appear to be links - that'll get you in more trouble and infect your machine too.


If you’ve been attacked, you need to go to Internet Information Services (IIS) on your server and cut user connections, and stop the site.  Then you need to find a good backup file to restore your database.  For that, you need to figure out when the attack happened so you can use a backup from before it happened.  If you don’t have a good backup, you'll probably have to clean the database manually to recover the data for your site

That means stripping out all the bad values and references that were injected.  You have to painstakingly go through every field, record and table.  In a big database, this can take forever, and it’s tedious and gut-wrenching work.  Worse, it may not be a complete solution.  The injection values are usually injected at the end of the existing values in the field, but if the injection values are longer than the field, they may write over the existing values, and that means the original data is lost.

When you’re done, you would turn IIS back on and see if you've done a good job, and whether there is some other gift they left for you.  You don't know until you bring the site up again and watch it work.

There are some scripts out there that say they can reverse the attack and clean the injected values out of your database. Here’s an example:


Different hackers inject different values, so there’s no guarantee that this will work.

Even assuming you can restore your database, you could have another attack any time with similar result.  So if you have a good backup file of your database, make a protected copy of it for future use if necessary.


Beyond that, you or your web designers need to close the vulnerabilities.  You can do that in a variety of ways, all of which involve new coding.  Go slowly and carefully, file by file, so you do it right and don't miss anything.

When you recode, you need to write routines to clean all the parameters that are being fed into your SQL queries.  To do this, you need to strip out any questionable SQL commands that could be part of an injection attack, including DECLARE, SELECT, SET, CAST, DROP, EXEC,”;", "--", INSERT, DELETE, XP_, VARCHAR and CHAR, among others.

This is also quite tedious for a website of any size, but necessary if you want to avoid doing the whole thing again.  There are also other things you can do to make your code less vulnerable.  Here's a couple of links that will help you understand what needs to be done.





There are some programs that claim to identify your vulnerability to SQL injection attacks.  One is the Acunetix Scanner, used by a great number of U.S. and foreign companies and government agencies.  I guess it must be of some value.  Check it at www.acunetix.com.

There are books that can help.  See O’Reilly’s SQL Hacks by Andrew Cumming and Gordon Russell available at Amazon and Barnes and Noble.


This global proliferation of SQL injection attacks is not only irritating, it's scary in that it has the ability bring sites down all over the world.  It’s time for Microsoft to catch up.  It's also time for world police authorities to catch up, and get serious.  This isn’t child’s play any more.

Posted in Uncategorized | 1 Comment »

One Response to “SQL Injection Attacks - how to deal with them”

  1. Apply food stamp:

    I wanted to research this subject and write a paper. Your post what a thousand words would not. Nice job.