5

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?

Anders
  • 64,406
  • 24
  • 178
  • 215
Grezzo
  • 632
  • 1
  • 6
  • 12
  • 1
    You can review http://security.stackexchange.com/questions/26027/mitigation-strategies-for-response-spliting-attack for how HRS works – Ali Ahmad Jul 28 '13 at 22:24
  • Don't you need a blank line between `19` and `` to actually terminate the headers so that `` is interpreted as the start of the body instead of as a malformed header? – Mike Samuel Jun 21 '14 at 13:12
  • 1
    "this is supposed to make my browser display "Grezzo"" Perhaps you meant "Graeme"? The string "Grezzo" appears nowhere in your headers. – Mike Samuel Jun 21 '14 at 13:14

4 Answers4

11

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...

AviD
  • 72,138
  • 22
  • 136
  • 218
0

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.

Logioniz
  • 121
  • 1
  • 7
0

just make sure to use the carriage return. The PHP Charset Encoder only encodes in %0A, but it should be %0D%0A to get a newline in the response. Only if this is done, the response is interpreted as HTTP 200 OK (or whatever you want).

Steven Volckaert
  • 1,193
  • 8
  • 15
Thomas
  • 1
-2

I also got stuck here for some time. It turns out that our WebGoat is Linux version. Linux only uses LF, so when encoding the parameters, only use %0a, instead of %0d%0a.

Xiang Pan
  • 1