Microsoft has developed a tool that lets web server administrators ensure the security of their servers. The tool, URLScan, screens all incoming requests to the server, and filters them based on rules set by the administrator. This significantly improves the security of the server by helping ensure that it only responds to valid requests.
URLScan is effective in protecting web servers because most attacks share a common characteristic – they involve the use of a request that’s unusual in some way. For instance, the request might be extremely long, request an unusual action, be encoded using an alternate character set, or include character sequences that are rarely seen in legitimate requests. By filtering out all unusual requests, URLScan prevents them from reaching the server and potentially causing damage.
URLScan is extremely flexible. Its default rule set fully protects a server against virtually all known security vulnerabilities affecting IIS, as well as potentially protecting against additional, as-yet undiscovered attack methods. The default rules can be modified – and new rules can be added – in order to customize the tool’s actions to match the needs of a particular server.
UrlScan.ini
UrlScan's operation is controlled by the UrlScan.ini file. This file should reside in the same directory as UrlScan.dll, and contains the sections and options listed below. The location that UrlScan is installed to is %windir%\system32\inetsrv\urlscan which is normally c:\winnt\system32\inetsrv\urlscan.
Note that UrlScan only reads the .ini file at initialization time (for performance reasons). It is necessary to stop and start the web service before any changes to this file will be effective. You an stop and restart the web service using these methods:
- Run the IISRESET.EXE command line utility
- Open a DOS window and type in NET STOP W3SVC and then NET START W3SVC
- Right clicking the server name in Internet Service Manager and selecting to Restart IIS. Selecting "Restart internet services on "
Also note that the default options built into UrlScanl.dll will result in a configuration that will reject all requests to the server. It is necessary to provide a UrlScan.ini file for UrlScan to pass requests to be served. A sample UrlScan.ini file is provided that contains the recommended settings to defend against known attacks against IIS servers at the time of writing.
The [Options] section configures UrlScan's main options, listed below:
UseAllowVerbs
Allowed values are 0 or 1. If 1, then UrlScan will read the [AllowVerbs] section of the ini file and reject any request containing an HTTP verb that is not explicitly listed. The [AllowVerbs] section is case sensitive. If 0, then UrlScan will read the [DenyVerbs] section of the ini file and reject any request containing an HTTP verb listed. The [DenyVerbs] is not case sensitive.
The default for UseAllowVerbs is 1.
UseAllowExtensions
Allowed values are 0 or 1. If 1, then UrlScan will read the [AllowExtensions] section of the file and reject any request where the file associated with the URL is not explicitly listed. If 0, then UrlScan will read the [DenyExtensions] section of the ini file and reject any request where the file extension associated with the request is listed. Both the [AllowExtensions] and [DenyExtensions] sections are case insensitive.
The default value for UseAllowExtensions is 0.
NormalizeUrlBeforeScan
Allowed values are 0 or 1. If 1, then UrlScan will do all of its analysis on the request URLs after IIS decodes and normalizes them. If 0, then UrlScan will do all of its analysis on the raw URLs as sent by the client. The default value for NormalizeUrlBeforeScan is 1.
Note that only advanced users, who are very knowledgeable about URL parsing, should set this option to 0, as doing so could expose the IIS server to canonicalization attacks that bypass proper analysis of the URL extensions.
VerifyNormalization
Allowed values are 0 or 1. If 1, then UrlScan will verify normalization of the URL. This action will defend against canonicalization attacks where a URL contains a double encoded string in the URL (i.e., The string "%252e" is a double encoded '.' character because "%25" decodes to a '%' character, the first pass decoding of "%252e" results in "%2e", which can be decoded a second time into '.') If 0, then this verification is not done.
The Default value for VerifyNormalization is 1.
Note that this option is dependent on the NormalizeUrlBeforeScan option.
AllowHighBitCharacters
Allowed values are 0 or 1. If 1, then UrlScan will allow any byte to exist in the URL. If 0, then UrlScan will reject any request where the URL contains a character outside of the ASCII character set. This feature can defend against UNICODE or UTF-8 based attacks, but will also reject legitimate requests on IIS servers that use a non-ASCII codepage.
The default value for AllowHighBitCharacters is 1.
AllowDotInPath
Allowed values are 0 or 1. If 1, then UrlScan will reject any requests containing multiple instances of the '.' character. If 0, then UrlScan will not perform this test. Because UrlScan operates at a level where IIS has not yet parsed the URL, it is not possible to determine in all cases whether a '.' character denotes the extension or whether it is a part of the directory path or filename of URL. For the purposes of extension analysis, UrlScan will always assume that an extension is the part of the URL beginning after the last '.' in the string and ending at the first '?' or '/' character after the '.' or the end of the string. Setting AllowDotInPath to 1 will defend against the case where an attacker uses a path info to obfuscate the true extension of the request (ie. something like "/path/TrueURL.asp/BogusPart.htm").
Note that this will also cause UrlScan to deny any request that contains a '.' in a directory or file name.
The default value for AllowDotInPath is 0.
RemoveServerHeader
Allowed values are 0 or 1. If 1, then UrlScan will remove the server header on all responses. If 0, then this action will not be performed.
The default value for RemoveServerHeader is 0.
Note that this feature is only available if UrlScan is installed on IIS 4.0 or