Hi With respect to the IIS/5.0 48K "bug" (see "HTTP Request Smuggling", http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf, pages 6-7 or 4-5), Noam Ben-Yochanan commented that IIS/5.x provides with the programmer with a way to consume the request body (beyond the 48K usually read), thus disabling the HTTP Request Smuggling caused by this anomaly. Noam sent me a link that explains this: Microsoft Knowledge Base article #810957: http://support.microsoft.com/default.aspx?scid=kb;en-us;810957 The short story is that IIS reads the body in buffers of 48KB (the default value of UploadReadAheadSize in the MetaBase registry). It probably always reads the first buffer. Now, the HTTP Request Smuggling trick works by sending any Content-Type OTHER THAN application/x-www-form-urlencoded. This means that IIS has nobody parsing the data and consuming more data, so it stops reading after those 48K, and whatever comes next is considered the next request (while MS says it is "by design", in my opinion this is still a bug, and with security implications). As Noam noted, it is possible to "artificially" consume the data using Request.BinaryRead, e.g. something like: Dim data data = Request.BinaryRead(Request.TotalBytes) And by this, restore order. So a possible solution is to insert the above code in every ASP page. However, there is a serious downside to this method: if a page accesses Request.BinaryRead, it cannot access the Form collection (see the documentation of BinaryRead in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/html/c84b1f88-1a8a- 4370-95de-e907f7fdd5e7.asp). Here's an improved solution. Note that the Content-Type of the request must be anything other than application/x-www-form-urlencoded for the attack to work (I understand now that this is due to the fact that in application/x-www-form-urlencoded, the IIS ASP.dll consumes the request body in fullness). So if a script wants to secure itself, it should check whether the Content-Type (accessible via ServerVariables("HTTP_CONTENT_TYPE") is application/x-www-form-urlencoded. If it is, then the script can proceed as usual, and access the data through the Request.Form collection. If the Content-Type is not "application/x-www-form-urlencoded", then the script should consume the data (as in the above example), and log the event (since this is probably an attack). Ideally, the script would terminate the TCP connection, but I don't know whether a script can terminate the TCP connection in a reliable manner. Perhaps sending a "Connection: Close" header can do the trick (or a 400 status code?). So the proposed solution would be something like (pardon me for any ASP syntax error): If (Request.ServerVariables("HTTP_CONTENT_TYPE") <> _ "application/x-www-form-urlencoded") Then ' Log a security error condition ' Consume leftover data Dim data data = Request.BinaryRead(Request.TotalBytes) ' Exit gracefully - do not proceed to normal flow EndIf ' Work as usual, can access Request.Form Still, it requires every ASP page to embed this kind of code. I think this makes the solution infeasible. And frankly I still call this a bug (be it by design or not) - an ASP page should not worry about its content-type or consuming the request body. Thanks again to Noam! -Amit
