- forging a response means an HTTP Response splitting issue, but here the 1.5 query hijacinghijacking trick is an HTTP Request splitting issue
- even if you were able to send a 302 redirect response to the user, this response would not contain the user credentials, and when following the redirection the victimvictim's browser would not send the first website credentials.
- we have TRACE available on the backend, so we want to force the victim HTTP query to be a TRACE query (soimplying building the first line of the HTTP query with a TRACE request and adding the real victim query to that unterminated query).
- TRACE will echo the victim credentials (cookies) in the Response body
- We want to see the response body (that's the very hard thing, as by default the response goes to the victim, not to the attacker)
- you need to have a response from the backend for the first query in the pipeline (If you take Apache, for example, you will never get this first response until the pipeline is complete). This way the reverse proxy can believe everything is done and can reuse the tcp/ip connection with the victim query.
- you need to have a connection reused between the Reverse Proxy and the Backend (so a keepalive connection or a tcp/ip sockets spool)
- All this already means several exploits were used (to hide the 0.5 query from the reverse proxy, like with an hidden header, and quite certainly another to trick the backend in revealing this header and interpret the body as another unterminated query). It also means the attacker is quite certainly running a long loop of strange queries hoping to capture one of the victim query sometime (and that's a blind attack).
The result is only hijacking the user credential for the 0.5 query (so you decide for the user what is the query runnedrunning on the backend), but the response goes to the victim, and he will see that the wrong query was done. You do not have the user credentials, you just have control on the victim queries. You do not even have the victim responses.
- req B and req C are hidden from the reverse proxy (same attack as the classical one one but you hide one complete and one iompleteincomplete response)
- req C is a TRACE query, unterminated (unterminated header)
[?3]may need to appear in a very strict and different order (
[?2]), and and that's tricky.
- same thing for
[?5]has more chances of succeeding
- if you have a way to control the timing of request B (slow query), you may succeed
[?2]. That's harder for
- socket buffering poisoning issues may help you avoiding these timing issues. the The reverse proxy would store the response and reuse it on the next query (not checking checking that the socket already had a response before adding a request in it).
- you have to hope the
[Someone]will be the attacker, the attack is running on on a loop so this may effectively happen (but it also means
req. Dis in fact
- there's more than one way to fail this sort of attack. That's really very theoretical.
- who's still running Trace enabled backends? I known you can enforce it in Apache,
but but Apache cannot be the backend in this attack, has incomplete pipelines does not send
early early responses (so no
resp. Aand no