%5c类的漏洞 in asp/asp.NET

%5c类的 漏洞在asp不再复述 我们看看 它在asp.net下的问题

 

Microsoft ASP.NET vulnerability (updated Oct. 7th)

Microsoft announced a possible vulnerability in ASP.NET (http://www.microsoft.com/security/incident/aspnet.mspx ). There are not much details so far, but it refers to the "canonicalization" functionality and suggest to implement then hardening measures outlined in KB887459 (http://support.microsoft.com/?kbid=887459 ).

It appears that a particularly crafted request may confuse ASP.Net and allow access to otherwise protected directories.

If a web server receives a request for a particular URL (e.g. _http://server/somedirectory/filename), the 'somedirectory/filename' part has to be mapped to a particular file located on the server. This translation has been the source of many "directory traversal" bugs. The IIS unicode exploit is probably the most famous one.

After our original posting of this diary, a few users pointed to the following articles which provide more details then provided by Microsoft's advisory:
(Thanks to Chaouki & Daniel)

http://www.heise.de/security/news/meldung/51730 (german)
http://www.derkeiler.com/Mailing-Lists/NT-Bugtraq/2004-09/0068.html
http://blogs.devleap.com/rob/archive/2004/10/02/1803.aspx (italian)
http://www.k-otik.com/news/10052004.ASPNETFlaw.php (french)

It appears that by switching a '/' character in the URL with '/' or '%5C', the canonicalization routine will be confused. So if the URL:
http://www.example.com/secure/file.apx
is password protected, using the either of the following URLs will bypass the restriction:
http://www.example.com/secure/file.apx
http://www.example.com/secure%5Cfile.apx

In addition to the slash/back-slash confusion, one reader reports that inserting a space will bypass the URL restriction as well:
http://www.example.com/%20/secure/file.apx
(had no chance to validate this method so far)

突破二级目录
..%5c