I know it’s an old comic, but XKCD really hit the nail on the head with this one.  It is something that I deal with on a regular basis and I think there are a lot of people out there who still don’t really understand the concept of SQL Injection, how it works, and how to get away from it.  While working with a client who fell victim to a SQL Injection attack on their website, I wrote some information for them to take and use as reference for what SQL Injection is, how to prevent it, and what to do about it when it happens.  I have generalized that info and hopefully it can help some others.

If you look at the snippet below you have an example of what might show up in your IIS logs if you were hit by one of the many sql injection attacks that have been going around the internet recently. I have changed the information to be similar to one of these common attacks, but modified to be something non-malicious. You can read more about the common attacks that have been happening lately here: http://forums.iis.net/p/1148917/1867511.aspx What the common attacks do, is they search through your entire database and find all varchar, nvarchar, text, and ntext values in every table in the database and update their values to include a reference to a malicious JavaScript on specific websites. Then, when your site displays the value of those fields, you end up displaying the malicious code to the visitors of your site through the new value inserted by the attack. Once that happens the JavaScript can take advantage of any unpatched vulnerabilities on the victims machine and possibly install a virus or spyware. Interestingly, some of these viruses will actually make it so as you are browsing websites it runs SQL injection tests on each of the pages you visit, and when it finds one it will exploit it the same way it was exploited upon you, making the victim the attacker.

2009-03-123 14:59:33 209.73.25.65 GET /page.asp id=248;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0x435245415445205441424C45205B64626F5D2E5B546573745D280D0A095B69645D205B696E745D204944454E5449545928312C3129204E4F54204E554C4C2C0D0A095B76616C7565315D205B766172636861725D2835313229204E4F54204E554C4C2C0D0A095B76616C7565325D205B6269745D204E4F54204E554C4C2C0D0A090D0A09434F4E53545241494E54205B504B5F546573745D205052494D415259204B455920434C5553544552454420280D0A09095B69645D204153430D0A0929205749544820280D0A09095041445F494E44455820203D204F46462C200D0A0909535441544953544943535F4E4F5245434F4D5055544520203D204F46462C200D0A090949474E4F52455F4455505F4B4559203D204F46462C200D0A0909414C4C4F575F524F575F4C4F434B5320203D204F4E2C200D0A0909414C4C4F575F504147455F4C4F434B5320203D204F4E0D0A0929204F4E205B5052494D4152595D0D0A29204F4E205B5052494D4152595D3B0D0A0D0A414C544552205441424C45205B64626F5D2E5B546573745D204144442020434F4E53545241494E54205B44465F546573745F76616C7565325D202044454641554C5420282831292920464F52205B76616C7565325D3B%20AS%20VARCHAR(4000));EXEC(@S);--|23|800a000d|Type_mismatch:_'[string:__248;DECLARE_@S_VARCH_]' 80 - 83.25.197.62 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+5.1;+.NET+CLR+2.0.50727) 500 0 0

If this happens to your site, first and foremost you will need to restore your old data into your database to get back what was lost and to remove the dangerous scripts from your webpage so it doesn’t hurt any visitors. If you do not have the option of shutting your site down while you protect the code from SQL injection, it is best to restore the data afterwards, since it could end up being wasted time if someone does SQL injection after the data is restored and before you protect all of the code. Once you have the data restored or before if you can’t take down the site temporarily, you still have to update the vulnerable code on your web application(s). Keep in mind that the location of this code depends on how your site was developed and set up, but it could be anywhere that SQL is called to pull information to display on the site through a querystring telling the page to load a certain database record or where user input is allowed and not validated. These pages would be vulnerable and would need to be fixed.

The part of that querystring from the “;DECLARE” to the “–” is the actual SQL injection code. SQL Server will interperet that because the attacker put a semi-colon after the id number. This tells SQL “this is the end of the command, remaining text is a new command.” Then the “–” tells SQL that the rest is a comment so that in case you are doing other things like sorting the results or grouping anything will not be recognized and SQL will execute the whole command. The CAST part actually just takes a binary value and converts it to a string. The value above converts to the following block of code and just creates a dummy table, whereas a malicious attacker would be doing something much worse.

CREATE TABLE [dbo].[Test](
[id] [int] IDENTITY(1,1) NOT NULL,
[value1] [varchar](512) NOT NULL,
[value2] [bit] NOT NULL,

CONSTRAINT [PK_Test] PRIMARY KEY CLUSTERED (
[id] ASC
) WITH (
PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON
) ON [PRIMARY]
) ON [PRIMARY];

ALTER TABLE [dbo].[Test] ADD CONSTRAINT [DF_Test_value2] DEFAULT ((1)) FOR [value2];

The next snippet is a perfect example of vulnerable code that would allow SQL injection through. While I am using classic ASP for my example, it could really be any language that doesn’t have a built in mechanism for checking your SQL queries such as PHP, Perl, ASP.Net, etc. Any page which executes an ad hoc SQL query based on a query string passed in or user input, without being validated, will be vulnerable to SQL injection. Instead of using something like conn.execute(“select * from [table] where value=” & request(“parameter”)) you should instead be either using a stored procedure to pass the value (see: http://www.asp101.com/samples/viewasp.asp?file=storedprocs.asp) or at the very least you should be checking the query string parameter for validity before inserting it into your query.

strSQL = "select * from table_name where id_column=" & REQUEST("id") & " order by sort_column"
SET objDB = objConn.EXECUTE ( strSQL )

While stored procedures are the best way to protect yourself, there are still instances where you could have a problem such as if you used a stored procedure where the code was actually generating a dynamic SQL statement internally based on parameters that were passed in, so you would have to protect those SPROCs as well from characters that can cause problems. See also: http://msdn.microsoft.com/en-us/library/ms161953.aspx and http://www.sqlsecurity.com/FAQs/SQLInjectionFAQ/tabid/56/Default.aspx There are many “paged results” stored procedures around where you can say essentially “give me the records for page 4 when we have 50 records per page” and mose of these are vulnerable to the same issue because they make use of adhoc queries such as the one below. The following snippet shows an example of a stored procedure that would not save you here.

CREATE PROCEDURE usp_mySelectFromNameTable
@mName varchar(50),
@mTable varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @query varchar(150)
SET @query = 'select id from ' + @mTable + ' where user_name=''' + @mName + ''''
EXEC(@query)
END

In the future, when writing code that will interface with your database, you should always be using parameterized queries for accessing information from the database. It takes a little extra code and effort, but in the long run you are much safer this way. If there were ever a case where you were storing usernames, passwords, and other personal data, in theory someone could use SQL injection to actually retrieve that information from your database and would have access to any other information available as well.

SQL Injection is a very real problem(http://news.google.com/news?hl=en&q=sql+injection+attack) that is continually being exploited due to lazy programmers, sloppy coding, or sadly, sometimes when a developer is just rushed through a project and they forget. We all need to remember to do proper checks of our inputs and paramaterize our queries and hopefully this issue will be less of a problem… at least until the next technology comes out with a different way to exploit it.