URLScan - First Line of Defense

By Paladion

March 27, 2009

In this blog we look at how URLscan can be a useful first line of defense against attackers. We discuss the various configuration settings and how URLscan 3.0/3.1 can be used to protect against application layer attacks.
Attached with this blog are two files.
1.) URLScan.txt: Instructions to install and configure URLscan on IIS
2.) A UrlScan.ini file that can be used to protect against popular application attacks like SQL injection and Cross Site Scripting. The ini file can be used for IIS webserver hosting ASP, ASP.NET, PHP (all web applications).
Note:- The right place to fix application vulnerabilities is in the application. Using URLScan to protect against attacks should only be a stop gap measure. Moreover,URLscan does not filter HTTP POST.
So lets get started...
URLscan has been around since 2001 when Microsoft released it to protect attacks against IIS 5.0 webservers. At that time typical attacks included directory traversal, Webdav exploits etc. URLscan would work as a ISAPI filter to monitor URLs, HTTP Request headers to look for directory traversal strings like (%,, ../ etc).
The typical URLscan filters that are configured on IIS are:

  • Deny access to various serverside scripts (except asp, .aspx)
  • Deny access to static sensitive files (.config, .log) etc.

.htw ; Maps to webhits.dll, part of Index Server
.ida ; Maps to idq.dll, part of Index Server
.idq ; Maps to idq.dll, part of Index Server
.htr ; Maps to ism.dll, a legacy administrative tool
.idc ; Maps to httpodbc.dll, a legacy database access tool
.shtm ; Maps to ssinc.dll, for Server Side Includes
.shtml ; Maps to ssinc.dll, for Server Side Includes
.stm ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services
; Deny various static files
.ini ; Configuration files
.log ; Log files
.pol ; Policy files
.dat ; Configuration files
.config ; Configuration files
For the above to be applied, set
[AllowVerbs] specifies the HTTP methods that are allowed. This effectively disables TRACE HTTP method and all Webdav methods
For the above to be applied, set
IIS6.0 is secure by default and the above settings come pre-configured with IIS 6.0
As IIS webservers have become secure, the focus of attacks has turned towards the applications hosted on them. Attackers are no longer restricted to specific versions of webservers.
SQL injection is one such popular attack on applications. It is simple to conduct and requires no or limited knowledge of the underlying webserver or operating system of the target system.
Clearly the best way to protect against a SQL injection attack is using parameterized sql queries and filtering inputs.
Attackers flood websites with SQL injection attacks. Even if applications are secure against SQL injection attack, such automated SQL injection attacks are invalid requests for the application. We need a way to prevent these attacks from reaching the application.
Fortunately, Microsoft has come up with URLScan 3.0/3.1, which allows web server administrators to extend the functionality of URLscan.
URLscan 3.0/3.1 now look for QueryStrings within the URL. The way we can extend the URLscan functionaility is using the [Rulelist] option. A [Rulelist] allows configuration of custom filters.
A Sample [Rulelist] configuration with custom filters to protect against SQL injection is given in the blog-
and is listed below
RuleList=SQL Injection
[SQL Injection]
DenyDataSection=SQL Injection Strings
ScanUrl=0 //Option to SCAN URL
ScanHeaders= // OPTION to SCAN HTTP HEADERS, example: Cookie
[SQL Injection Strings]
%3b ; a semicolon
@ ; also catches @@
char ; also catches nchar and varchar
create // this will filter urls with ?action=create
delete // this will filter urls with ?action=delete
exec ; also catches execute
sys ; also catches sysobjects and syscolumns
update // this will filter urls with ?action=update
Rulelists can be used to check querystrings, HTTP Headers: Cookie, and the URL itself.

Tags: Uncategorized