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
authenticated.

Example
-------

The webroot for your website is:

c:\inetpub\wwwroot\mysite

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

c:\inetpub\wwwroot\mysite\secure\web.config

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".

Bug
---

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:

http://localhost/secure%5Csomefile.aspx

_________________________________

Interestingly (and I guess now somewhat amusingly) Microsoft point out in
the article "Design Guidelines for Secure Web Applications"
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/h
tml/THCMCh04.asp):

"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 ;-)

____________________________________