In which settings is it possible to launch a HTTP Response Splitting Attack but not completely replace the HTTP message?

Question

I wondered in which settings is it possible to launch a HTTP Response Splitting Attack but not completely replace the HTTP message?

The examples I saw all allowed full replacement of the HTTP response, which made me think the attacker could have just replaced the full HTTP response in the first place.

I considered that there might be setups, where multiple components had control over parts of the HTTP message, e.g. one application would only be able to access headers. Or that some server might only be able to redirect HTTP-traffic (URL-redirect exploiting the GET-parameter which later on translates into a header field), but not read-write the body's contents.

However, I am missing a realistic scenario as an example. Can you explain me when HTTP response splitting is successful, but a full HTTP response-replacement not?

Answer 1

Let's see what are the usages of Splitting attacks.

But first thing to remember is that the final target is not the attacker, but HTTP agents between the attacker and the backend having the splitting issue. And one other detail, all this works using HTTP Pipelining (where you can send several requests without waiting for individual responses).

One of the first usage is security filter bypass. You send 2 requests, but the splitting occurs on the first one and the backend respond with 3 responses. The second one is the new one, it's based on a query that the first did not saw (let's say the ssl terminator or a reverse proxy cache, or any http load balancer). or this agent there were request 1 and request 2, and when receiving back 3 responses it will usually discard the 3rd response. Then content of response 2 comes from a hidden request (like a request which was hidden in the 1st request body, and only 'discovered' by the backend -- because there's an HTTP splitting issue exploited on this backend). The very fact that this request was hidden prevents the first agent from applying any security rule on this request (let's say this Load balancer should prevent access to /admin/* urls, now you can hide the /admin/ request and use splitting to get the /admin response on an innocent /foo query).

Attacker        Reverse Proxy cache         Backend
  |                  |                        |    
 req1[reqA]------->req1[reqA]--------------->req1,
 ,req2               |                       reqA, <-- splitting issue
  |                 req2-------------------->req2
  |                  |                        |
  |                  |<---req1, respA, resp2--+
  |<--- req1, respA--+                        |

Next usages is Cache poisoning (instead of asking /admin in the hidden request you ask for /script.js and you set the 2nd request url to /, now / content will be replaced by the script content instead of the home page in the Reverse Proxy Cache).

Third classical usage is quite hard to implement, but it works with incomplete responses or incomplete queries. With responses or queries from other users completing the incomplete responses or requests. That's usually more a thing with request splitting than response splitting. But the main idea is to get a request or response with elements coming from other users (in the case of request you could get the cookie or bearer tokens of other users added to your headers, in case of response this is more about the page content). You can get more detail on this type of attacks on all HTTP smuggling papers.

I can think of another bad usage, the complete mix-up of all requests and responses. On my first example I've been nice saying that the 3rd response was discarded. Some bad HTTP agents could also become completely crazy when the counter of requests and responses are bad. And they could start sending wrong responses to everyone.