URLScan Defeats ASP.NET Forms Authentication Vulnerability
In case you're just crawling out from under a rock, a vulnerability in ASP.NET Forms Authentication has been reported: http://www.microsoft.com/security/incident/aspnet.mspx.
This issue has to do with canonicalization of URLs. In brief, this is where two different forms of a file name resolve to the same file. There's a brief example and discussion here: http://support.microsoft.com/?kbid=887459. Fiddling with URLs in this way is an old trick, and script kiddies have automated tools that will try and “URL Walk“ to various directories they are interested in. URL Walking affects IIS as well as Apache servers if not protected properly.
In this instance, the URL www.protectedsite.com/default.aspx is protected by forms authentication. However, www.protectedsite.com\default.aspx and www.protectedsite.com%5Cdefault.asp are not protected. The ASPNET engine is not resolving the incorrect '\' in the URL. In IE, the incorrect '\' is automatically converted to a correct '/', but not in FireFox.
However, the IIS utility URLScan prevents these URLs from evenbeing passed to the ASPNET engine. In the urlscan.ini file, the [DentUrlSequences] section contains a list of characters that will result in the URL being blocked. Part of mine reads:
[DenyUrlSequences]
.. ; Don't allow directory traversals
./ ; Don't allow trailing dot on a directory name
\ ; Don't allow backslashes in URL
If you try either of the vulnerable URLs in either FireFox or IE, yuor are greeted with a 403.2 “Permission Denied“ error. The resulting URLScan log entry reads (IP addresses munged by me, long line may wrap):
[10-06-2004 - 09:47:50] Client at xxx.xxx.xxx.xxx: URL contains sequence '\', which is disallowed. Request will be rejected. Site Instance='1', Raw URL='%5Cdefault.aspx'
If you are running IIS 5 and don't have URLScan installed, do so now. You'll find it at http://www.microsoft.com/windows2000/downloads/recommended/urlscan/default.asp.
From what I understand, IIS 6 includes part of URLScan in it already. Maybe an IIS 6 expert can comment on whether or not the [DenyUrlSequence] is included.
I have tested this on a couple IIS 5.0 machines (both prod and dev), and can confirm this to be true on those machines.