Using the URLScan Security Tool

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

URLScan version 2.5 is a security tool that restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, the URLScan security tool helps prevent potentially harmful requests from reaching the server. URLScan 2.5 will install on servers that are running IIS 4.0 and later versions of IIS.

Note: Microsoft has now released URLScan 3.0. This augments URLScan 2.5 with additional functionality, including the ability to filter based on query strings, which can help reduce the effect of SQL injection attacks.

New Features in URLScan 2.5

Microsoft has re-released version 2.5 of the URLScan security tool with a new installer that performs a clean install of URLScan 2.5 on computers that are running IIS 4.0 and later versions of IIS.

Important: While the URLScan 2.5 security tool helps protect your server from attacks, you should always evaluate and apply the latest security updates from Microsoft. As new security vulnerabilities are discovered, Microsoft publishes updates such as service packs and hotfixes. To help reduce any risks such vulnerabilities might present, you must apply these security updates as they become available.

The URLScan security tool contains two files, URLScan.dll and URLScan.ini, that are packaged together in URLScan.exe. This latest update of URLScan 2.5 gives administrators even more control over URLScan configuration and provides additional functionality that helps administrators secure and lock down a server.

URLScan 2.5 introduces the following features, which are not available in earlier versions:

  • Changing the log file directory

  • Logging long URLs

  • Restricting the size of requests

Changing the Log File Directory

The LoggingDirectory option is used to specify the folder in which the log file is stored. This value must be the absolute path (for example, C:\Directory_Path) of the log file directory. If you do not specify a folder, URLScan creates the log file in the same folder where URLScan.dll is located.

Logging Long URLs

The LogLongUrls option has been added to increase the length of URLs that are logged. In earlier versions, URLScan truncated the log lines to 1024 bytes. The new option allows for enhanced logging by increasing the limit to 128 kilobytes (KB). Allowed values are 0 or 1, and the default value is 0. If LogLongUrls is set to 1, then URLScan will log up to 128 KB per request. If the value is set to 0, then log entries contain only the first 1024 bytes.

Restricting the Size of Requests

The RequestLimits section has been added so that URLScan can enforce limits on the size, in bytes, of separate parts of requests reaching the server. The RequestLimits section includes the following three entries:

  • MaxAllowedContentLength: Enforces a maximum value to content length. It does not actually prevent the server from necessarily reading in more data than the value specifies. For example, if a client makes a chunk transfer encoded POST, this URLScan option is not effective in tracking the size of the entity in the request. The default value is ~2 GB (2,000,000,000 bytes).

  • MaxUrl: Restricts the length of the request URL, in bytes, but it does not restrict the length of the query string. When you upgrade URLScan by using the installer, the default value is 16 KB.

    Note: If you manually extract URLScan.dll from URLScan.exe and you do not update URLScan.ini, the default setting will be 260 bytes. In this case, you will have to add MaxUrl = 16384 to URLScan.ini to overwrite the default setting.

  • MaxQueryString: Restricts the length of the query string, in bytes. The default value is 4 KB.

You can impose a byte limit on the size of a specific request header by prepending Max- to the name of any header. For example, the following entry imposes a limit of 100 bytes on the "Content-Type" header: Max-Content-Type=100. To list a header without specifying a maximum value, use 0. For example, Max-User-Agent=0. Also, any headers that are not listed in the RequestLimits section are not checked for length limits.

Determining Whether to Use URLScan 2.5 with IIS 6.0

Microsoft Windows Serverâ„¢ 2003 has many built-in features that help secure IIS 6.0 servers. URLScan provides some additional functionality, such as verb control, beyond what IIS 6.0 provides. Also, some organizations have integrated URLScan features into their server management practices for IIS and for other Microsoft servers. If you want to use the additional functionality and features of URLScan 2.5 or just maintain your current security management, then consider installing and using URLScan with IIS 6.0.

URLScan 2.5 is not included with IIS 6.0 because IIS 6.0 has built-in features that provide security functionality that is equal to or better than most of the features of URLScan 2.5. Table 1 compares how the features of IIS 6.0 and URLScan 2.5 handle certain security issues. Read the comparison to help you decide whether to install URLScan 2.5 on your servers that are running IIS 6.0.

Table 1: URLScan 2.5 Features Compared to IIS 6.0 Built-in Features

URLScan 2.5 Feature IIS 6.0 Built-in Capability

DenyExtensions: This feature was implemented in URLScan to limit the attack surface of the server by preventing, based on file name extensions, specific requests from running ISAPI or CGI code on the server.

IIS 6.0 limits the attack surface of the server by letting administrators specify the ISAPI and CGI code that can run on the server. Because IIS 6.0 specifies the code directly, you do not have to know which file name extensions in the URL can invoke the code.

DenyVerbs: WebDAV code can be invoked on a Web server based on the use of particular HTTP verbs. This feature was implemented in URLScan to limit the attack surface of the server by preventing requests that would invoke WebDAV.

IIS 6.0 lets administrators explicitly enable or disable WebDAV. Since this action affects the WebDAV executable code directly, you do not have to inspect the HTTP verb that is associated with each request.

DenyHeaders: WebDAV code can be invoked on a Web server based on the presence of particular HTTP headers. This feature was implemented in URLScan to limit the attack surface of the server by preventing requests that would invoke WebDAV.

IIS 6.0 lets administrators explicitly enable or disable WebDAV. Since this action affects the WebDAV executable code directly, you do not have to inspect the HTTP header that is associated with each request.

NormalizeUrlBeforeScan: This feature lets administrators specify whether IIS will process the raw URL that is sent by the client or the canonicalized URL that is processed on the server. Note: It is not practical to set this value to 0 on a production server. When this value is set to 0, all file name extensions and other URL checks in the URLScan.ini file must specify all possible encodings of each character. The number of resulting permutations would be almost impossible to manage on a production server.

The lockdown mechanism that is built into IIS 6.0 is based on the executable code that is permitted to run; it is not based on the URL that the client requested. For this reason, NormalizeUrlBeforeScan is not required on IIS 6.0.

VerifyNormalization: URLScan was designed to run on many versions of IIS. The code that handles URL canonicalization has been improved with later releases and service packs of IIS. This feature lets URLScan detect potential issues with URL canonicalization on unpatched systems.

The HTTP.SYS component used by IIS 6.0 has improved canonicalization code that has been specifically written to help protect against URL canonicalization attacks.

DenyUrlSequences: This feature was implemented in URLScan to enable URLScan to detect sequences that are used in URL-based attacks on a Web server.

It is not necessary for IIS 6.0 to deny URL sequences. By design, IIS 6.0 is not susceptible to URL-based attacks that use any of the character sequences listed in the default DenyUrlSequences section of the URLScan.ini file provided by Microsoft.

AllowDotInPath: The URLScan lockdown me ism depends on a filter notification that occurs very early in the processing of a request. At this time, URLScan cannot know for sure how IIS will parse the URL for PATH_INFO. It is possible that PATH_INFO will affect the file name extension on the URL. Setting AllowDotInPath to 0 will cause URLScan to reject any request where the file name extension is ambiguous due to a dot-in-path condition.

The AllowDotInPath feature is not required in IIS 6.0 because IIS 6.0 does not depend on filter notifications for its lockdown mechanism.

RemoveServerHeader: This feature enables URLScan to remove or change the identity of the server from the "Server" response header in the response to the client.

IIS 6.0 does not include the RemoveServerHeader feature because this feature offers no real security benefit. Most server attacks are not operating system-specific. Also, you can detect the identity of a server and information about the operating system by mechanisms that do not depend on the server header.

EnableLogging, PerProcessLogging, and PerDayLogging: URLScan is not part of the core IIS server. URLScan is an add-on utility that produces its own log files. These settings control aspects of how URLScan produces and names its log files.

IIS 6.0 logs all its lockdown activity in the W3SVC logs. Requests that are rejected because of lockdown or executable code are identified by 404 errors that occur with sub-error 2 (404.2) in the logs. Requests for static files that are rejected because of an unknown type are identified by 404 with sub-error 3 (404.3) in the logs.

AllowLateScanning: This feature lets administrators specify whether URLScan examines URLs before or after other filters. There are several filters that modify URLs, and it might be desirable for URLScan to examine the URL after it has been modified. The FrontPage Server Extensions filter is an example of such a filter.

The AllowLateScanning feature is not required in IIS 6.0 because IIS 6.0 does not depend on filter notifications for its lockdown mechanism. The lockdown mechanism built into IIS 6.0 is based on the executable code that is allowed to run, not on the URL that the client requested.

RejectResponseUrl: This feature works together with UseFastPathReject. If UseFastPathReject is set to 0, then any rejected requests will be remapped to the URL specified by RejectResponseUrl. If the specified URL does not exist, the client will receive an ordinary 404 response just as if the client had requested a non-existent page. If the specified URL does exist, the server can customize the response that is sent to the client.

In IIS 6.0, a request that is rejected due to a lockdown of executable code will generate a 404.2 custom error. A static file that is rejected because of an unknown MIME type will generate a 404.3 custom error. Administrators can use the IIS custom error mechanism to control these responses.

UseFastPathReject: The URLScan lockdown mechanism depends on a filter notification that occurs very early in the processing of a request. As a result, if URLScan rejects the request directly from this notification, the typical 404 response cannot be generated. Instead, the client will receive a terse 404 response and not the rich custom error that ordinarily occurs. If UseFastPathReject is set to 0, URLScan will remap the request to the URL specified by RejectResponseUrl.

IIS 6.0 does not depend on filter notifications for its lockdown mechanism. In IIS 6.0, a request that is rejected because of the lockdown of executable code will generate a 404.2 custom error. A static file that is rejected because of an unknown file type will generate a 404.3 custom error. Administrators can use the IIS custom error mechanism to control these responses.

AllowHighBitCharacters: This feature enables URLScan to detect non-ASCII characters in URLs.

The character range that is allowed is handled by HTTP.SYS. This value can be changed by modifying the following registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\EnableNonUTF8 Caution: Incorrectly editing the registry could severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

MaxAllowedContentLength: This feature enables URLScan to set limits on the size of requests that are posted to the server.

IIS 6.0 has the built-in capability to limit the size of requests, which is configurable by the MaxRequestEntityAllowed and ASPMaxRequestEntityAllowed metabase properties.

MaxUrl, MaxQueryString, and MaxHeader: These settings enable URLScan to set limits on the sizes of URLs, query strings, and specific headers that are sent to the server.

The HTTP.SYS component used by IIS 6.0 enables size limits to be set on various parts of the request. The values can be changed by modifying AllowRestrictedChars, MaxFieldLength, UrlSegmentMaxLength, and UrlSegmentMaxCount in the registry under the following registry keys:

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\AllowRestrictedChars

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\MaxFieldLength

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxLength

  • HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\HTTP\Parameters\UrlSegmentMaxCount

Caution: Incorrectly editing the registry could severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Why has URLScan been made available for use with IIS 6.0? URLScan provides a small level of additional functionality beyond what IIS 6.0 provides. URLScan is a flexible tool that some customers use for purposes that are not covered in this article. Some organizations have integrated URLScan features into their server management practices for IIS and for other Microsoft servers. For any one or more of these reasons, some customers might decide to install URLScan 2.5 and use it with IIS 6.0.

For more information about URLScan 2.5, see the Microsoft Knowledge Base article 307608, Using URLScan on IIS.

Installing URLScan 2.5

URLScan 2.5 installs as a clean install on a computer that is running IIS 4.0 or a later version of IIS. Upgrade scenarios are also supported.

To install URLScan 2.5

  1. Download the Setup.exe file for URLScan 2.5.

  2. Double-click the Setup.exe icon.

  3. Review the agreement in the URLScan Installer Package End User Agreement and then click Yes to accept the agreement and continue. If you click No, the installer will close.

  4. When the installer has finished running, you receive the following message: "URLScan has been successfully installed." Click OK to close the installer.

To uninstall URLScan

  1. In Control Panel, double-click Add or Remove Programs.

  2. Select URLScan 2.5 and then click the Change/Remove button.

  3. When URLScan 2.5 has been removed from your server, you receive the following message: "URLScan has been successfully uninstalled." Click OK to complete the uninstall process.

Understanding the URLScan 2.5 Installer

When installing URLScan 2.5, the URLScan 2.5 installer does the following:

  • Installs the URLScan.dll and URLScan.ini files in the %windir%\system32\inetsrv\urlscan directory. If URLScan is already installed on the computer, the URLScan.ini file is updated with any new settings that are not present in the current configuration file.

  • Adds URLScan as a global filter to IIS.

When installing URLScan on a server that is running IIS 6.0, the URLScan 2.5 installer makes some additional changes that enable URLScan 2.5 to work with the new IIS 6.0 process model. These changes are as follows:

  • PerProcessLogging is set to 1 in the URLScan.ini file. This ensures that two URLScan processes do not write to the log file at the same time.

  • URLScan is marked as cache-aware in the metabase. This ensures that two or more worker processes that are running URLScan do not write to the log file at the same time.

  • A new log directory, which is a subdirectory located under the ..\inetsrv\urlscan directory, is created. This ensures that the URLScan directory is not cluttered with all of the log files that the PerProcessLogging option will create.

When installing URLScan 2.5 on IIS, the installer sets permissions for URLScan.dll, URLScan.ini, and the log file. When installing URLScan 2.5 on IIS 6.0, the installer sets additional permissions on the same files to enable URLScan 2.5 to work with IIS 6.0 worker process isolation mode. Table 2 lists the IIS permissions that are set when URLScan 2.5 is installed.

Table 2: URLScan 2.5 IIS 6.0 Permissions

File/Directory Permissions

..\inetsrv\urlscan\urlscan.dll

Read and Execute (set on IIS 6.0 only): LocalService, IIS_WPG, and NetworkService

Full: Administrators, and LocalSystem

..\inetsrv\urlscan\urlscan.ini

Read (set on IIS 6.0 only): IIS_WPG, LocalService, and NetworkService

Full: Administrators, and LocalSystem

..\inetsrv\urlscan\logs

Read and Write (set on IIS 6.0 only): IIS_WPG, LocalService, and NetworkService

Full: Administrators, and LocalSystem

If a version of URLScan is detected on the computer, the installation will be considered an upgrade. In the upgrade scenario, the changes that the installer makes will be the same as for a clean installation unless you have configured a custom log directory. If you have defined a different location for the URLScan logs, then the new logs directory will not be created.

Frequently Asked Questions

Question: What is URLScan?

Answer: URLScan is a security tool that screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator. Filtering requests helps secure the server by ensuring that only valid requests are processed. URLScan helps protect Web servers because most malicious attacks share a common characteristic that involves the use of a request that is unusual in some way. For instance, the request might be very long, request an unusual action, be encoded using a different character set, or include character sequences that are rarely seen in legitimate requests. By filtering unusual requests, URLScan helps prevent such requests from reaching the server and potentially causing damage.

Question: Will URLScan 2.5 work with IIS 6.0?

Answer: Yes. URLScan 2.5 is the only version of URLScan that Microsoft supports for use with IIS 6.0.

Question: I'm already using URLScan 2.0. Why should I download this update?

Answer: URLScan 2.5 includes new features that have been added to help improve the security of servers that are running IIS. These new features are as follows:

  • Changing the log file directory

  • Logging long URLs

  • Restricting the size of requests

Question: I've already configured URLScan for my site. Will URLScan 2.5 overwrite my current configuration settings?

Answer: No. The installer adds only new entries to your existing configuration file. URLScan supports all of the configuration settings from earlier versions of URLScan.

Question: If URLScan 2.5 helps protect my server against certain vulnerabilities, is it still necessary to apply security updates?

Answer: Yes. To help protect your server from any new or existing security vulnerabilities, you must evaluate and apply the latest security updates as soon as they are available.

Question: I'm not sure if I'm using chunked-transfer encoding in any of my custom applications. What is it?

Answer: Chunked-transfer encoding is an HTTP/1.1 feature that transmits the message body in a request or response as chunks that are stamped with their size. HTTP 1.1 allows clients to send POST requests by using chunked-transfer encoding. In most cases, IIS will automatically decode these requests before they are processed. If the size of the request exceeds a particular threshold (by default, 48 KB), then the ISAPI or CGI code to which the request is directed must enable chunked-transfer encoding before the request can be processed correctly. If you have code running on a server that is receiving POST requests and you are not sure whether it supports chunked-transfer encoding, then consider using URLScan to prohibit requests that include a "Transfer-Encoding" header. For more information about chunked-transfer encoding, see section 3.6.1 of RFC 2616, "Hypertext Transfer Protocol ? HTTP/1.1."