Skip to main content

UrlScan Security Tool

UrlScan 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.

What is the current version of the UrlScan Security Tool

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 running IIS 4.0 and later.

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, patches, or hotfixes. To help mitigate any risks such vulnerabilities might present, you need to apply these security updates as they become available.

The UrlScan security tool comprises two files ? UrlScan.dll and UrlScan.ini ? that are packaged together in UrlScan.exe. This latest update of UrlScan 2.5 gives administrators even greater control over UrlScan configuration and provides functionality that helps administrators further secure and lock down the 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 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.

Top of page Top of page

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 utilize the additional functionality and features of UrlScan 2.5 or simply 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 running IIS 6.0.

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

UrlScan 2.5 FeatureIIS 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 allowing administrators to specify the ISAPI and CGI code that can run on the server. Because IIS 6.0 specifies the code directly, it is not necessary to know which file extensions in the URL are capable of invoking 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 allows administrators to explicitly enable or disable WebDAV. Since this action affects the WebDAV executable code directly, it is not necessary 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 allows administrators to explicitly enable or disable WebDAV. Since this action affects the WebDAV executable code directly, it is not necessary to inspect the HTTP header that is associated with each request.
NormalizeUrlBeforeScan: This feature allows administrators to 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 virtually 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 necessary 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 allows UrlScan to 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 allow 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 URLbased 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 extension is ambiguous due to a dot-in-path condition.The AllowDotInPath feature is not necessary in IIS 6.0 because IIS 6.0 does not depend on filter notifications for its lockdown mechanism.
RemoveServerHeader: This feature allows UrlScan to remove or alter 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, it is possible to 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. Rather, 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 of its lockdown activity in the W3SVC logs. Requests that are rejected due to lockdown or executable code are identified by 404 errors with sub-error 2 (404.2) in the logs. Requests for static files that are rejected due to an unknown type are identified by 404 with sub-error 3 (404.3) in the logs.
AllowLateScanning: This feature allows administrators to specify whether UrlScan examines URLs before or after other filters. There are a number of 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 necessary 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 in conjunction 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 a normal 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 due to 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 that occurs very early in the processing of a request. As a result, if UrlScan rejects the request directly from this notification, the normal 404 response cannot be generated. Rather, the client will receive a terse 404 response instead of the rich custom error that normally 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 due to lockdown of executable code will generate a 404.2 custom error. A static file that is rejected due to 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 allows 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 allows UrlScan to place 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 allow UrlScan to place 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 allows 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 of these reasons, some customers might choose 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.

 

Microsoft réalise une enquête en ligne pour comprendre votre opinion sur le site Web de. Si vous choisissez de participer, l’enquête en ligne vous sera présentée lorsque vous quitterez le site Web de.

Souhaitez-vous y participer ?