News

IIS Tool Filters SQL-Injection Attacks

Microsoft’s UrlScan 3.0 is an improved security filter for Internet Information Services Web server designed to prevent SQL-injection attacks.

• By Kurt Mackie
• 09/15/2008

Microsoft released an improved security filter for its Internet Information Services (IIS) Web server that is designed to help thwart SQL-injection attacks. The free application, called UrlScan 3.0 -- the release to Web version -- is an add-on tool to IIS that provides real-time verification of HTTP server requests, potentially blocking malicious code. A SQL-injection attack is a direct attack on SQL Server by means of malicious code in a query string, which is passed to SQL Server through an Internet app. If the right safeguards are not in place, the code can be executed by Microsoft SQL Server, causing havoc on the Web site's back-end.

SQL-injection attacks have become a worldwide problem in the last eight months or so. They have commonly affected Web sites built using Microsoft's popular ASP or ASP.NET code, or code enabling dynamic Web sites.

New Strings
UrlScan has been available for about five years, but Microsoft added some new features in version 3.0. Perhaps the most important improvement is that UrlScan 3.0 provides support for query-string scanning.

For technical reasons, previous versions of UrlScan did not examine the query string in the server request. Instead, UrlScan version 2.5 blocked server requests based on aspects such as URL string length, according to Wade Hilmo, Microsoft's senior development lead on the IIS product team -- the team that wrote UrlScan.

"In [UrlScan] 3.0, we added the ability to do filtering based on the query string, in addition to the URL," Hilmo says. "We also added the ability to create more granular rules that can be targeted to specific types of requests. For example, you can write a rule that only applies to ASP pages or PHP pages, which is something you'd never be able to do in UrlScan 2.5."

Another improvement for developers is the ability to specify a safe list of URLs and query strings that can bypass UrlScan checks. In addition, version 3.0 uses W3C-formatted logs for ease of analysis.

Are these developments in UrlScan 3.0 a big step for Microsoft in addressing security? Kevin Beaver, founder and principal information security consultant of Atlanta-based Principle Logic LLC, doesn't think so. Beaver is a Certified Information Systems Security Professional (CISSP) and consultant, providing independent information and advice on security.

"The new things they're doing in UrlScan 3.0 -- such as providing the ability to scan query strings and custom rules -- are pretty basic," Beaver writes in an e-mail. "It's good the features are now available, but getting admins and developers to actually upgrade is a whole different issue."

Version 3.0 of UrlScan is compatible with the configuration files administrators used with version 2.5, so those settings are retained on an upgrade to a production server. Microsoft also added support for 64-bit IIS processes with this version.

Microsoft's latest Web server, IIS7, already has UrlScan 2.5 features built into the Request Filter, Hilmo says. Microsoft plans to update IIS7 with the new 3.0 features.

While that sounds convenient, Beaver added some caveats to just relying on UrlScan 3.0 as a means of defense.

"Installing such a tool on the Web server isn't the perfect scenario for two reasons," Beaver says. "No. 1: It serves as a cover-up for coding flaws, and No. 2: Blocking such malicious traffic should 'ideally' be at the network level -- a Web application firewall, for example. That said, UrlScan is priced right and works pretty well. Therefore, most admins and developers are going to choose it as their layer of protection."

Server Protection Only
UrlScan 3.0 is by no means a Web security cure-all. Hilmo describes it as a "stopgap measure" that can be used to protect the server. Security ultimately needs to be enforced in the Web application itself, he adds.

"Really, the application running on the server is the only piece of code that actually knows what the SQL query is intended to do," Hilmo explains. "So the fix for the root cause is for application developers to go in and do the validation and make sure that the SQL data that they're sending to the SQL Server is what they intend."