HTTP pipelining - indirect security implications

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

Received on Thursday, 2 April 2009 08:46:33 UTC