full-disclosure - IISShield and ASP.NET canonicalization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <200410132004138.SM02028@void>
From: thalm at void.my-bulldog.com (Tiago Halm)
Subject: IISShield and ASP.NET canonicalization

All,

A lot of fuzz has come around the canonicalization issue found with IIS and
ASP.NET forms authentication. One of the main worries has been if IISShield
is an effective measure to prevent this kind of exploit.

So, is it effective? Yes!

Since ISAPI Filters will be the main topic, here goes. ISAPI Filters have
several notifications to which they can subscribe and these notifications
are the various steps through which an Http Request goes through before
reaching the intended script map ISAPI Extension to which it is destined.
Each ISAPI Filter installed in IIS has a chance to do something (parse,
modify) to the contents of that Http Request (each ISAPI gets a chance to
its own thing in the exact order they are installed in IIS).

Only after the ISAPI Filters process the pre-execution notifications, is
when IIS delivers the Http Request to the appropriate script map ISAPI
Extension. ASP.NET, with its associated extensions - aspx, asax, ashx,
etc.., is handled by one of those ISAPI Extensions called
C:\WINNT\Microsoft.NET\Framework\<framework version>\aspnet_isapi.dll
(IIS5).  In IIS6, the ISAPI Extension of ASP.NET has another name I do not
recall right now. These extensions deal with all the details of the ASP.NET
execution request. After ASP.NET terminates the processing of the Http
Request, it then delivers it the ISAPI Filters "kingdom" again. And now, the
Http Response (now its called response, since it is an answer to a request)
must then travel through the post-execution notifications where again the
ISAPI Filters have their opportunity to parse/modify the Http Response.
So, every Http Request reaching IIS goes through the ISAPi Filter
notifications where there is an opportunity to parse the request.

KodeIT IISShield reliably protects IIS from any encoding attempt of a URL be
it:
- Hexadecimal escape codes
- UTF-8 variable-width encoding
- UCS-2 Unicode encoding
- Double encoding

Tiago Halm
KodeIT Development Team
http://www.kodeit.org

---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]