- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 8 Apr 2009 16:33:14 +1000
- To: Amit Klein <aksecurity@gmail.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Thanks, Amit. Do you think you could take a stab at a proposal for text that would be appropriate to put in Security Considerations? It doesn't have to be conclusive, just highlight the risks to implementers. Sections 5 and 6 of <http://tools.ietf.org/html/rfc3552> may be useful, if you're willing to take this on. Cheers, On 02/04/2009, at 7:45 PM, Amit Klein wrote: > Hi > > I want to draw your attention to an application (not HTTP-level) > vulnerability whose impact can be amplified by HTTP pipelining. In > other words, starting to support HTTP pipelining (which is not an > issue in itself!) in earnest may result in increasing the attack > surface of an application level vulnerability. > > About five years ago, I published a paper describing the "HTTP > Response Splitting" attack > (http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf > ). > At that time, HTTP pipelining support was practically non-existent. > Clients (browsers) didn't pipeline by default, and proxy servers > "de-pipelined" incoming requests, so that if several requests were > sent by their client, they would send a single request to the upstream > server, receive its request, send it to the client and only then > process the next (queued) request. > > This behavior made it harder to really exploit the HTTP Response > Splitting vulnerability: the server did send out two responses, but > the proxy (or the client) could: > - Ignore the excess data (bad for the attacker - needs to carefully > time the attack so that the second request arrives before the second > response from the server) > - Ignore part of the excess data (e.g. up to the buffer end, or the > packet end) - bad for the attacker since the attacker needs to study > the systems and understand what are the buffer/packet limits. > - Queue the excess data (that was ideal from the attacker's > perspective, yet in the wild, it was not a very popular architecture). > > I believe pipelining changes all that - proxy servers (and clients at > large) will probably opt for queuing excess data, which would make > HTTP Response Splitting attack much more effective. > > Again - this isn't a problem with pipelining in itself. The problem is > at the application level (allowing the HTTP Response Splitting > condition), but there are many vulnerable applications out there, and > "suddenly" pushing HTTP pipelining may adversely affect them. And I > know HTTP pipelining is not new, it is part of RFC 2616, but perhaps > this is the place to make notes about possible security implications. > > Thanks, > -Amit > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 8 April 2009 06:33:55 UTC