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 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.
.gif)
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 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 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.
Top of page
Installing UrlScan 2.5
UrlScan 2.5 installs as a clean install on a computer running IIS 4.0 or later. Upgrade scenarios are also supported.
To Install UrlScan 2.5
- Download the Setup.exe file for UrlScan 2.5.
- Double-click the Setup.exe icon.
- 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.
- When the installer completes, the following message is displayed: "UrlScan has been successfully installed." Click OK to close the installer.
To Uninstall UrlScan
- In Control Panel, double-click Add or Remove Programs.
- Select UrlScan 2.5 and then click the Change/Remove button.
- When UrlScan 2.5 has been removed from your server, the following message is displayed: "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 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 does not get 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 allow 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.
Top of page
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 they involve the use of a request that is 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 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 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, Microsoft strongly recommends that you 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 needs to be aware of chunked-transfer encoding to process the request 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."
Top of page