Microsoft Knowledge Base Email Alertz

(887459) - Describes how to add more safeguards to an ASP.NET application to help protect against common canonicalization issues.

Search KbAlertz

Advanced Search

Receive Microsoft Knowledge Base articles by E-Mail?

Every night we scan the Microsoft Knowledge Base. If technologies you're interested in are updated, we'll send you an e-mail. You only get one e-mail a day, and only when new articles are added.

Click here to create a
FREE account
Already have an account?
[Click here to Login]











Microsoft Knowledge Base Article

This article contents is Microsoft Copyrighted material.
©2005-©2007 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks

Article ID: 887459 - Last Review: December 3, 2007 - Revision: 2.5

How to programmatically test for canonicalization issues with ASP.NET

Disclaimer

The information that is provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. We disclaim all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages. Therefore, the foregoing limitation may not apply.

On This Page

INTRODUCTION

This article describes how to add safeguards to an ASP.NET application to help protect against common canonicalization issues.

MORE INFORMATION

What is canonicalization?

Canonicalization is the process that determines how various equivalent forms of a name are resolved to a single standard name. The single standard name is also known as the canonical name. For example, on a specific computer, the names c:\dir\test.dat, test.dat, and ..\..\test.dat might all refer to the same file. Canonicalization is the process that maps such names to a name that is similar to c:\dir\test.dat.

When a URL is received by a Web server, the server maps the request to a file system path that determines the response. The canonicalization routine that is used to map the request must correctly parse the URL to avoid serving or processing unexpected content. For more information about canonicalization, visit the following Microsoft Web site:
http://msdn2.microsoft.com/en-us/library/aa302420.aspx (http://msdn2.microsoft.com/en-us/library/aa302420.aspx)
We recommend that you use best practices to help safeguard your applications. For additional information, see the following section.

Adding additional canonicalization safeguards to your Web application

Microsoft ASP.NET developers can add more checks to help reduce canonicalization issues for a Web application by adding an Application_BeginRequest event handler in their Global.asax file that is stored in the root directory of the Web application. This event handler executes for each Web request. You can add code to this event handler to help safeguard against canonicalization issues.

Code sample

The following code samples demonstrate how to add an Application_BeginRequest event handler to a Global.asax file. This event handler helps prevent invalid characters and malformed URLs by performing path verifications. Therefore, you can avoid common canonicalization issues.

Global.asax code sample (Visual Basic .NET)

<script language="vb" runat="server">
Sub Application_BeginRequest(Sender as Object, E as EventArgs)
    If (Request.Path.IndexOf(chr(92)) >= 0 OR _
        System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then
        Throw New HttpException(404, "Not Found")
    End If
End Sub
</script>

Global.asax code sample (C#)

<script language="C#" runat="server">
void Application_BeginRequest(object source, EventArgs e) {
    if (Request.Path.IndexOf('\\') >= 0 ||
        System.IO.Path.GetFullPath(Request.PhysicalPath) != Request.PhysicalPath) {
        throw new HttpException(404, "not found");
    }
}
</script>

APPLIES TO
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 1.1
  • Microsoft .NET Framework 1.0
  • Microsoft .NET Framework 1.0 Service Pack 1
  • Microsoft .NET Framework 1.0 Service Pack 2
  • Microsoft .NET Framework 1.0 Service Pack 3
  • Microsoft .NET Framework 1.1
  • Microsoft .NET Framework 1.1 Service Pack 1
Keywords: 
kbsecurity kbtshoot KB887459
       

Community Feedback System

Very often, it takes hours to solve a problem. Very often, you've looked high and low, and have tried a lot of solutions. When you finally found it, chances are, it was because someone else helped you. Here's your chance to give back. Use our community feedback tool to let others know what worked for you and what didn't.

Please also understand that the community feedback system is not warranted to be correct, it's simply a system that we've built to let people try and help each other. If something in a feedback response doesn't make sense to you, or you're not comfortable making changes that the feedback talks about (like registry edits), please consult a professional.

Thank you for using kbAlertz.com Feedback System.

-- Scott Cate

Jason
Written: 10/7/2004 1:42 PM
I thought URLscan already did the same thing they are suggesting in the article. If we have URLScan installed why should we add the code mentioned in the article?

Zahid Nawaz - znawaz NOSPAM-AT-NOSPAM acrologix.com Reported as Irrelevant  
Written: 10/8/2004 12:27 AM
This article is fruitful for the sack of security as well as functional performance.

Jeremy SImmons - http://jeremysimmons.net Reported as Irrelevant  
Written: 10/8/2004 9:20 AM
This is for Jason <The following are exertps from Microsoft.com. Specifically http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HT_URLScan.asp > URLScan is an ISAPI filter that allows Web site administrators to restrict the kind of HTTP requests that the server will process. By blocking specific HTTP requests, the URLScan filter prevents potentially harmful requests from reaching the server and causing damage. URLScan blocks requests that contain potentially harmful characters, for example, characters that have been used to exploit vulnerabilities in the past such as "." used for directory traversal. It is not recommended that project paths contain the "." character. If you must allow this, you need to set AllowDotInPath=1 in URLScan.ini. <End Microsoft.com Quotes> Yes, URLScan does do the same 'thing' (blocking a period to avoid canononical traversal) only in the sense that it accomplishes it as an end result. It does not do the same 'thing' (provide a total vector for safety. The problem is that if you deploy a webapp to a customer's box, you cannot ensure that they have (or will have) Urlscan installed. If you the vendor do not take steps to make sure that kind of functionality is provided within the app, you're going to loose one (if not many more) customers.