Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working through OWASP's "WebGoat" (version 5.4) vulnerable web application, but I'm getting stuck on one of the earliest lessons which is to do with HTTP response splitting.

I've looked in all the hints and the solution (and even at all the tutorials dotted about the interwebs), but I still can't get it to work.

I've even completely modified my web server's response to:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost/WebGoat/attack?Screen=3&menu=100&fromRedirect=yes&language=en
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 19
<html>Graeme</html>
Content-Type: text/html;charset=ISO-8859-1
Content-length: 0
Date: Sun, 28 Jul 2013 20:26:13 GMT

I'm fairly confident that this is supposed to make my browser display "Grezzo", but instead it's following the first response rather than the second response. I even tried taking out the first "Content-Length: 0" line, but it makes no difference.

What's going on here? Am I missing something? Perhaps modern web browsers always follow the first response these days?

share|improve this question
1  
You can review security.stackexchange.com/questions/26027/… for how HRS works –  Ali Ahmad Jul 28 '13 at 22:24
add comment

2 Answers

The basic piece of HTTP Response Splitting (HRS) that gets left out most often, is the proxy.

HRS is not an attack between a webserver and a browser, or even a browser and a webserver.
The attack is on the idiosyncrasies of semi-compliant HTTP devices, namely, the web server and the web proxy.
Specifically, the attack takes advantage of the fact that the webserver sees one set of responses (one response), and the proxy sees a different set (two responses), and the proxy splits one request to the victim, and the other to the attacker (or the ether).

So, to best test this attack, you would need to set up:

  1. web server
  2. proxy
  3. victim browser
  4. attacker client (or browser)

I am assuming that you missed the proxy part...

share|improve this answer
add comment

I'm not hacker man), but i think that attack is server-dependent. So your attack is successful when server incorrectly handle the request (or incorrectly handle response).

Broswer always handle the first response (older browsers handle first response too).

But this attack will always work when server put some variable to one of the header (for example: Cookie) Simple example to understand: Client load page which have Textarea and button to submit request. When server handle request it put variable from Textarea to cookie (Do not ever do). So client may write on textarea this strings:

some data to cookies
Content-Type: text/html
Content-Length: 16

<H1>Hacked</H1>

So when server put to cookie this string the answer from the server would be such as this:

Connection:keep-alive
Content-Type:this server content-type (for example: application/json)
Set-Cookie:qqq="some data to cookies
Content-Length:16  -  your length
Content-Type:text/html - your content type 

<H1>Hacked</H1>

This is not server bug, this is bug of programmers which write web site.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.