How to configure URLScan 3.0 to mitigate SQL Injection Attacks

== Cross-posted from https://blogs.msdn.com/webtopics ==

The purpose of this blog post is to review the concept of SQL Injection attacks, to introduce URLScan 3.0, and to discuss how to configure URLScan 3.0 to block a SQL Injection attack that uses the Cookie header of an HTTP request as its attack vector.

What is a SQL Injection Attack?
There is a wealth of information online about SQL Injection Attacks and how to avoid them.  As explained on MSDN, a SQL Injection attack is “..an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution.” (https://msdn.microsoft.com/en-us/library/ms161953.aspx).  It is important to keep SQL Injection attacks in mind if you host a web application on IIS, and that web application accepts user input (like in a form on a webpage) that is then sent to a backend database. 

What is URLScan 3.0?
URLScan 3.0 is Microsoft’s newest version of the popular ISAPI filter that extends the security features already built in to IIS.  URLScan 3.0 adds some really great features into the IIS security arsenal, particularly in the area of blocking and filtering malicious HTTP requests.  URLScan 3.0 is fully supported on IIS 5.1, 6.0, and 7.0.  To obtain URLScan 3.0, use one of the links below:

URLScan 3.0 x86: https://www.microsoft.com/downloads/details.aspx?FamilyId=EE41818F-3363-4E24-9940-321603531989&displaylang=en

URLScan 3.0 x64: https://www.microsoft.com/downloads/details.aspx?familyid=361E5598-C1BD-46B8-B3E7-3980E8BDF0DE&displaylang=en

How do I configure URLScan 3.0 to block a SQL Injection attack?
The online documentation for URLScan does quite a good job at explaining the features and common configuration scenarios.  It also provides detailed information pertaining to the configuration file sections, what they do, and how to configure them.   You can find the documentation homepage at https://learn.iis.net/page.aspx/473/using-urlscan, and more specific details at https://learn.iis.net/page.aspx/476/common-urlscan-scenarios/. 

We recently had a customer using the documentation to configure URLScan to block a SQL Injection attack, and they mentioned that they found the documentation to be a bit confusing.  Following is a summary of what was wrong in their configuration, and how we fixed it.

The customer outlined that even though they had URLScan 3.0 configured to block SQL Injection attacks, they were still seeing evidence of an attack.  Upon inspecting the customer’s urlscan.ini file (the configuration file for URLScan), we were able to see that URLScan had not been configured to block the specific type of injection attack that was occurring.  Specifically, the customer’s IIS log showed evidence of an attack attempt inside of an HTTP request’s Cookie header.

Here is what the misconfigured SQL Injection rules looked like in the urlscan.ini file:

RuleList=SQL Injection [SQL Injection]AppliesTo=.asp,.aspxDenyDataSection=SQL Injection StringsScanUrl=0ScanAllRaw=0ScanQueryString=1ScanHeaders=SQL Injection Headers [SQL Injection Strings]--%3b ; a semicolon/*@ ; also catches @@char ; also catches nchar and varcharalterbegincastconvertcursordeclaredeletedropendexec ; also catches executefetchkillopenselectsys ; also catches sysobjects and syscolumnstable [SQL Injection Headers] AppliesTo=.asp,.aspxDenyDataSection=SQL Injection Headers StringsScanUrl=0ScanAllRaw=0ScanQueryString=0ScanHeaders=Cookie: [SQL Injection Headers Strings]--@ ; also catches @@altercastconvertdeclaredeletedropexec ; also catches executefetchinsertkillselect

Notice that in the "RulesList" entry, there is only one rule listed, called "SQL Injection".  This means that URLScan will only look for one rule, called "SQL Injection".  Under the “SQL Injection” section was a “ScanHeaders=SQL Injection Headers” entry.  What this was doing was telling the “SQL Injection” rule to check for an HTTP request header called "SQL Injection Headers" in all incoming HTTP requests.  Since “SQL Injection Header” is not a valid HTTP request header, no requests coming had that header and therefore the Cookie header configuration was not being applied.

To resolve the issue, we needed to configure two rules, one called "SQL Injection" and another called "SQL Injection Headers".  Then, in the "SQL Injection Headers" section, we added the Cookie header into the “ScanHeaders” section.  After making these changes, the SQL Injection configuration in the urlscan.ini file looked like this:

 

RuleList=SQL Injection,SQL Injection Headers [SQL Injection]AppliesTo=.asp,.aspxDenyDataSection=SQL Injection StringsScanUrl=0ScanAllRaw=0ScanQueryString=1ScanHeaders= [SQL Injection Strings]--%3b ; a semicolon/*@ ; also catches @@char ; also catches nchar and varcharalterbegincastconvertcursordeclaredeletedropendexec ; also catches executefetchkillopenselectsys ; also catches sysobjects and syscolumnstable [SQL Injection Headers]AppliesTo=.asp,.aspxDenyDataSection=SQL Injection Headers StringsScanUrl=0ScanAllRaw=0ScanQueryString=0ScanHeaders=Cookie [SQL Injection Headers Strings]--@ ; also catches @@altercastconvertdeclaredeletedropexec ; also catches executefetchinsertkillselect

Once these changes were made, URLScan successfully blocked incoming HTTP requests that contained a Cookie header whose value contained any of the strings in the “SQL Injection Headers Strings” section, as illustrated in the URLScan log file:

For more information on URLScan 3.0 and on mitigating SQL Injection attacks, I recommend the following links:

Using URLScan:
https://learn.iis.net/page.aspx/473/using-urlscan

SQL Injection (msdn):
https://msdn.microsoft.com/en-us/library/ms161953.aspx

SQL Injection and How To Avoid It:
https://blogs.msdn.com/tom/archive/2008/05/29/sql-injection-and-how-to-avoid-it.aspx

Filtering SQL Injection from Classic ASP:
https://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx