Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   Microsoft .NET Vendors:   Microsoft
Microsoft .NET Forms Authentication Can Be Bypassed By Remote Users
SecurityTracker Alert ID:  1011559
SecurityTracker URL:
CVE Reference:   CVE-2004-0847   (Links to External Site)
Date:  Oct 7 2004
Impact:   User access via network
Exploit Included:  Yes  

Description:   A vulnerability was reported in Microsoft .NET in the forms authentication. A remote user can bypass the authentication process.

In September 2004, Toby Beaumont reported that a remote user can supply an HTTP GET request with a specially crafted URL that contains a backslash instead of a forward slash to gain access to the requested resource without having to authenticate.

An demonstration exploit example URL is of the following format:


Impact:   A remote user can gain access to restricted resources without having to authenticate.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Access control error, Input validation error
Underlying OS:  Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Nov 10 2004 (Microsoft Has Issues a Workaround) Microsoft .NET Forms Authentication Can Be Bypassed By Remote Users
A workaround and some related tools are available.
Feb 8 2005 (Vendor Issues Fix) Microsoft .NET Forms Authentication Can Be Bypassed By Remote Users
Microsoft has issued a fix.

 Source Message Contents

Subject:  Security bug in .NET Forms Authentication


We believe we have discovered a serious flaw in .NET forms authentication
when used to secure sub folders.

A standard forms authentication setup requires the presence of "web.config"
to set the authentication method and login procedure. The presence of this
file prevents access to certain files (.aspx files for example) unless


The webroot for your website is:


You want to secure files in a sub directory "secure"


A request to http://localhost/secure/somefile.aspx would then redirect the
user to a predefined authentication page, as defined in web.config, before
allowing the user access to "somefile.aspx".


1. Using Mozilla not IE, you make a request to
http://localhost/secure\somefile.aspx The use of a backslash rather than a
forward slash appears to bypass the expected authentication model invoked in
.NET forms authentication

2. Using IE, you make a request to http://localhost/secure\somefile.aspx -
IE automatically replaces the backslash "\" with a forward slash "/" and
everything appears fine. However, replace the backslash "\" with %5C (%5C
being hex value for \) and all is not so fine:



Interestingly (and I guess now somewhat amusingly) Microsoft point out in
the article "Design Guidelines for Secure Web Applications"

"Be Careful with Canonicalization Issues:

Data in canonical form is in its most standard or simplest form.
Canonicalization is the process of converting data to its canonical form.
File paths and URLs are particularly prone to canonicalization issues and
many well-known exploits are a direct result of canonicalization bugs. For
example, consider the following string that contains a file and path in its
canonical form."

And then goes on to define the exploit ;-)

(Russ - I have not posted this message anywhere as yet, nor have I contacted
Microsoft. If you indeed confirm this exploit, you are the first to know).


Toby Beaumont
Director of Technology


This email and any attached files are for the exclusive use of the addressee
and may contain privileged and/or confidential information. If you receive
this email in error you should not disclose the contents to any other person
nor take copies but should delete it and telephone us immediately.

Creator makes no warranty as to the accuracy or completeness of this email
and accepts no liability for its contents or use. Any opinions expressed in
this email are those of the author and do not necessarily reflect the
opinions of Creator. 

If you or your employer does not consent to the receipt of emails of this
kind then please notify us immediately.

4 Grafton Mews
United Kingdom

Tel: 020 7391 5151
DDI: 020 7391 5128
Fax: 020 7391 5152


NTBugtraq Editor's Note:

Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the
 message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office
 messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the
 message and place it in your TO: field.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2022, LLC