Introduction
URLScan, a security tool, was provided as an add-on to earlier versions of IIS so administrators could enforce tighter security polices on their web servers. Within IIS 7.0, the IIS team has incorporated all the core features of URLScan into a module called Request Filtering and added a feature called Hidden Segments. This paper recaps each of the features Request Filtering provides and gives a real world example of how to apply it your environment.
This article contains:
Filter Double-encoded Requests
This feature prevents attacks that rely on double-encoded requests. This applies in a scenario in which an attacker submits a carefully crafted double -encoded request to IIS 7.0. If this occurs, IIS 7.0 may accept a request that it would otherwise reject. When this feature is enabled, IIS 7.0 will normalize the URL twice -- if the first normalization is different from the second, the request is rejected. When IIS 7.0 rejects a request for this feature, the error code logged is 404.11.
UrlScan equivalent
This was the VerifyNormalization option in UrlScan.
Example
In this example, a server administrator does not want IIS 7.0 to ever allow doubled encoded requests to be served. To implement this scenario, use the following configuration:
<configuration>
<system.webServer>
<security>
<requestFiltering
allowDoubleEscaping="false">
</requestFiltering>
</security>
</system.webServer>
</configuration>
Filter High Bit Characters
This feature either allows or rejects all requests to IIS 7.0 that contain non-ASCII characters.
When IIS 7.0 rejects a request for this feature, the error code logged is 404.12.
UrlScan equivalent
This was the AllowHighBitCharacters option in UrlScan.
Example
In this example, an administrator does not want to allow high bit characters for their entire server, but only for one application. To accomplish this, the administrator sets the allowHighBitCharacters="false" in the applicationHost.config; but within the application root they will create a web.config that allows that single application to accept non-ASCII characters. The configuration they would use in the web.config is as follows:
<configuration>
<system.webServer>
<security>
<requestFiltering
allowHighBitCharacters="true"
>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Filter Based on File Extensions
This feature defines a set of allowed file extensions that IIS 7.0 will serve.
When IIS 7.0 rejects a request for this feature, the error code logged is 404.7.
UrlScan equivalent
This was the AllowExtensions and DenyExtensions options in UrlScan.
Example
In this example, a server administrator never wishes to serve ASP files, but everything else is allowed. To accomplish this, the administrator sets the allowUnlisted option for fileExtensions to "true" and then defines a file extension entry to explicitly deny ASP as shown below:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true" >
<add fileExtension=".asp" allowed="false"/>
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Filter Based on Request Limits
This filter combines three features:
1. maxAllowedContentLength – this is the upper limit on the content size.
2. maxUrl – this is the upper bound on a URL length.
3. maxQueryString – this is the upper bound on the length of a query string.
When IIS 7.0 rejects a request for this feature, the error code logged is:
|
Status Code |
Reason |
|
404.13 |
Content Length too Large |
|
404.14 |
URL too Large |
|
404.15 |
Query String too Large |
UrlScan equivalent
Each of these values was available with the same names in UrlScan:
- maxAllowedContentLength
- maxUrl
- maxQueryString
Example
It is very common for companies to purchase software to which they do not have source code access. Over time, they find vulnerabilities in that code. Getting updates for the affected code is often not easy. Vulnerabilities such as these tend to be because a URL or Query String sent to the application is simply too big or too much content is being sent. Once the server administrators can determine a safe upper bound, they apply these limits using the configuration below, without having to patch their application binaries:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<requestLimits
maxAllowedContentLength="30000000"
maxUrl="260"
maxQueryString="25"
/>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Filter by Verbs
This feature defines a list of VERBS that IIS 7.0 accepts as part of a request.
When IIS 7.0 rejects a request for this feature, the error code logged is 404.6.
UrlScan equivalent
This was the UseAllowVerbs, AllowVerbs, and DenyVerbs options in UrlScan.
Example
An administrator only wants to allow one verb on their servers, GET. To accomplish this, the administrator first lockdowns the configuration to never allow any VERB by setting the allowUnlisted="false" option. Next, the administrator lists the VERBs they wish to explicitly allow. In this example, we only allow the verb GET:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<verbs
allowUnlisted="false"
>
<add verb="GET" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Filter Based on URL Sequences
This feature defines a list of sequences that IIS 7.0 rejects when it is part of a request.
When IIS 7.0 rejects a request for this feature, the error code logged is 404.5.
UrlScan equivalent
This was the DenyUrlSequences feature in UrlScan.
Example
This is a very powerful feature. Using the following configuration allows you to prevent a given character sequence from ever being served by IIS 7.0:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<denyUrlSequences>
<add sequence=".."/>
</denyUrlSequences>
</requestFiltering>
</security>
</system.webServer>
</configuration>
This example rejects the '..' sequence; but a more practical scenario would be if you purchased an application from a vendor who went out of business and you discovered the application was vulnerable when a given character sequence was sent to it. Using this feature, you can protect that application by simply adding that URL sequence to the denied list without having to patch the applications code.
Filter Out Hidden Segments
This feature allows you to define which segments are 'servable'.
When IIS 7.0 rejects a request for this feature, the error code logged is 404.8.
UrlScan equivalent
This was not part of UrlScan and is new to IIS 7.0.
Example
Consider the following example where there are two URLs on a server:
http://site.com/bin
http://site.com/binary
We want to allow content in the binary directory but not the content in the bin directory. If we were to use URL sequences and reject the sequence "bin," we would end up denying access to both URLs. By using the configuration shown below, we can deny access to bin but still have the content in binary served:
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<add segment="BIN"/>
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Summary
In previous versions, IIS administrators could use UrlScan at a global level to define security policies they wanted to enforce on their systems. With IIS 7.0 administrators, can still implement those polices at a global level but also per URL and leverage all they benefits that the new rich delegation model provides.
This document touched on several of the new error codes request filtering returns when it rejects a request. To summarize all of the error codes IIS 7.0 logs, the following list is provided below for easy reference:
|
Error |
Status Codes |
|
Site not found |
404.1 |
|
Denied by policy |
404.2 |
|
Denied by mime map |
404.3 |
|
No handler |
404.4 |
|
Request Filtering: URL Sequence denied |
404.5 |
|
Request Filtering: Verb denied |
404.6 |
|
Request Filtering: File extension denied |
404.7 |
|
Request Filtering: Denied by hidden segment |
404.8 |
|
Denied since hidden file attribute has been set |
404.9 |
|
Request Filtering: Denied because request header is too long |
404.10 |
|
Request Filtering: Denied because URL doubled escaping |
404.11 |
|
Request Filtering: Denied because of high bit characters |
404.12 |
|
Request Filtering: Denied because content length too large |
404.13 |
|
Request Filtering: Denied because URL too long |
404.14 |
|
Request Filtering: Denied because query string too long |
404.15 |
Related Content
Comments