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"
defaultUrl="/default.asp">
<protectedFileExtensions>
<add extension=".asp" />
<add extension=".aspx" />
</protectedFileExtensions>
<blackListPatterns>
<add patternRegex="(select|grant|delete|insert|drop|alter|replace|
truncate|update|create|rename|describe)\\s+.*\\s+(from|into|table|
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" />
</blackListPatterns>
</spfConfig>

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.

转载于:https://www.cnblogs.com/Safe3/archive/2009/05/23/1487608.html