How to Use Request Filtering

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
• Filter High Bit Characters
• Filter Based on File Extensions
• Filter Based on Request Limits
• Filter by Verbs
• Filter Based on URL Sequences
• Summary

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:

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:

Comments