Filtering for SQL Injection on IIS 6 and earlier
This article is specific to IIS 6 and earlier. If you are using IIS 7.0 or later, please see this article.
The IIS team has created an add-on tool for IIS called UrlScan that is able to filter HTTP requests. If a request is found to have contents deemed unacceptable to the administrator, it will be blocked before it is processed by a web application. This feature is useful as a mitigation tool in defense of SQL Injection vulnerabilities.
Note that any scheme that filters SQL Injection attempts is only a mitigation. The complete solution to the problem requires fixing vulnerable web applications. For more information about SQL Injection vulnerabilities and strategies for fixing them, here are some suggested links:
Definition of SQL Injection
SQL Server Injection Protection
Preventing SQL Injections in ASP
How To: Protect from SQL Injection in ASP.NET
Coding Techniques for protecting against SQL Injection in ASP.NET
Filtering SQL Injection from Classic ASP
Security Vulnerability Research & Defense Blog on SQL Injection Attack
Prerequisite
Before getting started, you will need the current version of UrlScan. As of the date of this writing, it is version 3.1. Most of the information here will also work with UrlScan 3.0, but there are a number of bug fixes in 3.1 and it is strongly encouraged that you upgrade if you are running an earlier version. A free download of UrlScan 3.1 can be found here.
Configuring UrlScan
UrlScan is configured via the urlscan.ini file.
- Open the urlscan.ini file in the following path:
%systemroot%\system32\inetsrv\urlscan\urlscan.ini
- Search the urlscan.ini file for "RuleList=" (without the quotes.)
- Add "SQLInjection" (without the quotes) to the end of the RuleList line. If there is already an item or items in the RuleList, use a comma to separate them.
- Create the following new sections at the end of the urlscan.ini file:
[SQLInjection]
AppliesTo=.asp,.aspx
DenyDataSection=SQLInjectionStrings
ScanURL=0
ScanAllRaw=0
ScanQueryString=1
ScanHeaders=[SQLInjectionStrings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
create
cursor
declare
delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update
- Save the changes to urlscan.ini.
What effect does this have on my server?
With the above configuration in place, IIS will look at each incoming request for pages with .asp or .aspx extensions to search for specific strings in the request's query string. If found, IIS will block the request and return a 404 Not Found page to the client. If you want to change the file extensions, you can add or remove file extensions on the AppliesTo line. The specific strings in the search are controlled by the entries in the [SQLInjectionStrings] section. If you want to change the strings, you can do so by adding or removing entries here.
It is worth noting that the above rule is fairly aggressive about blocking requests. If this is an issue for your content, it is possible to make specific URLs exempt from UrlScan filtering. To do this, search the urlscan.ini file for the [AlwaysAllowedUrls] section and add the exempt URLs (one per line.) Note that URLs here should not include "http://hostname.com" or "https://hostname.com". Follow the example in the urlscan.ini comments for this section. Also note that the behavior of this section has changed with UrlScan 3.1. If you are using UrlScan 3.0, you cannot bypass query string filtering in this manner.
Note that it is very important that you thoroughly check any URLs for SQL Injection vulnerabilities before adding them to the [AlwaysAllowedUrls] section!
How can I check my logs for SQL Injection attempts?
UrlScan logs all of the requests that it blocks in UrlScan log files. The default location for these files is %systemroot%\system32\inetsrv\urlscan\logs. Beginning with UrlScan version 3.1, these logs are in W3C compliant format. Rejections triggered by the above SQL Injection rule will have "rule+SQLInjection+triggered" in the x-reason field.
You can check these logs periodically to see if you've been getting requests with SQL Injection attempts and also to see if your rule may be blocking legitimate requests.
In Conclusion
This should be everything you need to know to get a quick start in filtering SQL Injection attempts with UrlScan on your server. For more information about things UrlScan can do, check out the articles here.
Happy UrlScan filtering,
-Wade