1

Doing the webgoat HTTP splitting exercise. I feel like I'm doing something wrong or there is something that I don't understand.

The idea is that since we can control the referer parameter, we can split the request into 2 and have the server sends us another response (This could later on be used to trick victims into caching our 2nd response with the expires parameter).

The thing is: I am not seeing anything. On the browser or on Burp suite.

I am trying the following payload (By intercepting the POST request after clicking "Search!" and replacing the sent string inside the html form box with the following):

test%0aContent-Length:%200%0a%0aHTTP/1.1%20200%20OK%0aContent-Type:%20text/html%0aContent-Length:%2017%0a<html>pwnd</html>

On Burpsuite I see the 302 and the following 200 with the payload appearing at the end of the path and that's it. Supposedly based on what I am reading on the solution tab, I should be redirected to a site with the html I injected.

Any idea what I might be doing wrong or what's happening?

Improve this question

1 Answer 1

Reset to default
0

HTTP splitting is not the simpliest attack. The target is not your browser, sometimes you could use CRLF injection to target the browser (like injection of Location: header) but really the whole domain of HTTP smuggling is not about targeting the attacker browser.

When a single HTTP request generates 2 or more HTTP responses and the communication occurs just between you (your browser) and the server nothing happens. The extra responses are just discarded.

Things are different when there are other actors between the attacker and the server. Think Load balancers, SSL/TLS terminators, Reverse Proxy caches. they became the target of the attack.

They saw 1 request incoming and they received several responses. Several things could happen:

  • they store the responses for next requests (socket poisoning), requests that could come from different users
  • you did not just send 1 request, but a pipeline of 2 request (see HTTP Pipelining), then the splitting will mix the results of your 1st bad request with the second one (cache poisoning)
  • also with a pipeline of 2 requests, the 2nd response is incomplete (the one you injected), the intermediary waits from more content from the backend before delivering it to you, if reusing the same tcp/ip connection for intermediary->server another user legitimate response could be appended to your incomplete response and you could receive it.

That's examples, but as you can see this is something quite complex and should maybe not have been added to webgoat examples (they are a lot of other attacks easier to understand and exploit) :-).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .