RSS Feed

Entries in SPF (7)


Using SPF to Protect Against SQL Injection Worms

When SPF was first released last month, I knew it was a great protection mechanism to thwart attacks against applications running on IIS. What I didn't realize was that the most urgent gap that it fills is that of thwarting SQL injection worms.

Microsoft has pitched UrlScan v3 as a band-aid solution to protect against SQL injection worm attacks on classic ASP and ASP.NET applications. The reality is that UrlScan's capabilities to protect applications-level attacks are quite limited. Specifically, UrlScan is not able analyze POST data and lacks support for regular expressions. This combined with the inability to include or exclude specific URLs leaves many users unable to adequately protect their vulnerable applications. Unfortunately with UrlScan it's an all or nothing approach.

SPF overcomes both of these shortcomings. Unlike UrlScan, SPF is specifically designed to thwart application-level attacks. UrlScan is not. UrlScan was originally designed to protect IIS web servers from the onslaught of web server attacks that surfaced shortly after the turn of the millennium (i.e. Code Red, Nimda, etc). UrlScan is very effective as a server-level protection mechanism; however the reality is that it simply was not designed to be an application-level protection mechanism.

Last week, an updated beta of SPF was released which has been significantly optimized for performance in Black-List only configuration mode. I have come up with the following sample configuration which can be used to protect IIS6 applications from SQL injection attacks (applications hosted on IIS7 can also use this configuration). Keep in mind that these patterns are designed to prevent false positive hits while still allowing most sites to function; using blanket deny rules against strings like "exec", for example, won't work in most real-world situations (strings like this occur way too often in most free-text submissions). I experienced this first-hand when attempting to implement UrlScan on a customer website using the sample SQL Injection rules published on the IIS.NET Security Blog.

The Black-List only sample configuration for SPF is shown below:

<spfConfig logDirectory="c:\\temp\\logs" protectForm="false" protectUri="false"
protectQueryString="false" protectCookie="false" protectMode="Active"

<add extension=".asp" />
<add extension=".aspx" />

<add patternRegex="(select|grant|delete|insert|drop|alter|replace|
database|index|view|set)" applyTo="all" />
<add patternRegex="'?\\s+OR\\s.+=" applyTo="all" />
<add patternRegex="(--|;|*|@@|0x|DECLARE|..|.dbo.)" applyTo="all" />
<add patternRegex="(CAST|EXEC|CHAR)(%|()" applyTo="all" />
<add patternRegex="(s|x)p_" applyTo="all" />

If anyone has any additional ideas on good SQL attack patterns to look for, feel free to share your thoughts. Keep in mind SPF BlackListPatterns are not case sensitive and are applied to decoded request data. As always, this is not intended to be permanent solution for SQL injection (as opposed to fixing your code); however it certainly raises the bar for bad guys and will buy you some time to implement the optimal fix.


IIS Secure Parameter Filter (SPF) Released

We have publicly released the Beta version of IIS Secure Parameter Filter (SPF) on our tools page. SPF is an application security module specifically designed to thwart parameter-based attacks against applications running on Microsoft IIS web servers. SPF requires minimal initial configuration and does not require making any modification to the underlying application code.

Those of you who attended the "Protecting Vulnerable Applications with IIS7" talk which I presented at Black Hat earlier this month will recognize SPF as the module which I demonstrated. The version we released today works with both IIS6 and IIS7 and is written in managed .NET code.

So what exactly does SPF do? SPF provides two primary protection mechanisms which are each explained in more detail below.

Tamper Protection

The tamper protection capabilities of SPF are primarily designed to thwart authorization attacks. Tamper protection works at the following levels:

  • URI Protection - Protected URI's require a cryptographic token to access. The only way to obtain a valid URI token is for the application to present you with a link to the URI. This is primarily designed to thwart direct browsing attacks where users can forcefully request pages for which they are not entitled
  • Query String Protection - Protected query string values are validated using a cryptographic token which ensures they were not tampered with. This protection is designed to secure embedded query string values from manipulation.
  • Form Field Protection - Protected form fields that contain embedded values (i.e. Hidden Fields and Select Lists) are encrypted to prevent un-authorized viewing or modification by malicious users.
  • HTTP Cookie Protection - Protected cookies are encrypted to prevent un-authorized viewing or modification by malicious users.

SPF tokens can also be bound to the calling user and set to expire, resulting in the ability to protect against Cross-Site Request Forgery and thwart certain types of hijacking, replay and cross-site scripting attacks.

Malicious Input Filtering

Malicious input filtering (referred to as Black List Protection) is designed to identify parameters that include known attack patterns. SPF supports Black List pattern matching against Query Strings, Post data, and Cookie values.

In some ways, this functionality can be compared to existing server filters like Microsoft's URL Scan, but SPF provides much more flexible capabilities. Black List Protection was originally not within the scope of SPF's protection mechanisms, however with the recent wave of SQL Injection worms it became apparent that URLScan (specifically the recently released 3.0 Beta version) is not sufficient for protecting web applications from attack.

URLScan is a good server-level protection mechanism that has been adapted to provide basic web application protection whereas SPF is designed specifically to defend web applications and therefore can provide more comprehensive protection against harmful input. SPF's Black List Protection provides the following:

  • Regular Expression Support - Provide a powerful mechanism for defining malicious input patterns
  • Flexible Request Entity Coverage ' Black List patterns can be applied to any combination of Query Strings, Post data or Cookie values. This level of HTTP request coverage is especially critical as SQL Injection worms become more advanced and move beyond exploiting Query String parameters. Specific URLs can also be excluded from Black List coverage for greater flexibility.

SPF is currently available for free download and use from CodePlex. The current Beta of SPF provides full protection for any application running on IIS7 and for ASP.NET applications running on IIS6. Non-ASP.NET applications on IIS6 will be limited to only the Malicious Input Filtering (Black-List) capabilities of SPF. A detailed administration guide is included with the download.

Page 1 2