Technical Note: Detecting and Testing HTTP Response Splitting Using a Browser

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

Technical Note: Detecting and Testing HTTP Response Splitting Using a 
Browser

Author: Amit Klein
 
The HTTP Response Splitting attack is quite unique in the sense that 
it is a pure web-application level attack (with the malicious data 
typically sent in one of the query/body fields) whose impact is 
observed at the HTTP level. Thus, while it's easy to use a browser to 
inflict response splitting, it's not that easy to observe the result 
of the attack through the browser.

Of course, there are ways to test HTTP Response Splitting without a 
browser, e.g. using raw interface TCP/HTTP tools, or by using "HTTP 
Response Splitting"-aware web application scanners. But this write-up 
is all about using the browser to detect the success (or failure) of 
HTTP Response Splitting.

The method I'm about to present has the following benefits:
1.      It works both for HTTP 2xx responses and HTTP 3xx responses.
2.      It works both for IE (tested with 6.0) and for Mozilla (tested 
with 1.4)

The idea is simple: instead of injecting the full HTTP Response 
Splitting attack, it usually suffices to demonstrate that a new, 
completely spoofed response header, can be injected. True, this does 
not demonstrate HTTP Response Splitting, but 9+ out of 10 cases, if 
injecting a new header works, so does the full HTTP Response 
Splitting attack.
The response header of choice is Set-Cookie. This is due to the fact 
that browsers can be configured to pop-up an alert when a cookie is 
received from the server.
The quick-witted reader will notice that this in fact constitutes a 
session fixation attack (the idea of using CRLF injection to achieve 
session fixation is discussed in the WebAppSec mailing list thread 
recorded here: http://www.securityfocus.com/archive/107/356508).

So what would a test look like? The payload should be as following:

%0d%0aSet-Cookie:%20HTTP_response_splitting%3dYES%0d%0aFoo:%20bar

When the original header is something like ($DATA is the parameter 
into which we inject):

Location: http://somewhere/script?x=$DATA&y=123

The injection will end up as:

Location: http://somewhere/script?x=
Set-Cookie: HTTP_response_splitting=YES
Foo: bar&y=123

Hence a (temporary/RAM) cookie named HTTP_response_splitting (with 
value "YES") will be introduced to the browser. Using the browser 
cookie pop-up alert, it's possible to monitor when and if such cookie 
is received.
If indeed such cookie pops-up, you still need to verify that this 
injection can be turned into HTTP Response Splitting. This can be 
done by injecting the full HTTP Response Splitting vector, and 
observing the results through a network sniffer (the browser won't 
help much, because it will only parse the first response).

Setting and observing a cookie alert:
In IE, setting the cookie alert is done by going to Tools -> Internet 
Options, choosing the  Privacy tab, clicking Advanced, then checking 
"override automatic cookie handling" and choosing "prompt" in the 
"First-party Cookies" column. Uncheck the "Always allow session 
cookies" if it is checked.
In Mozilla, this is done by going to Edit -> Preferences, choosing 
Privacy & Security, choosing Cookies, then checking "Enable cookies 
for the originating web site only", then checking  "Ask me before 
storing a cookie".
During HTTP Response Splitting testing, in IE you may get a "Privacy 
Alert" window informing that the site attempts to set a cookie. In 
such case click on "More Info" and observe the cookie name and value.
In Mozilla, a "Confirm" alert window may pop-up. Click on "Show 
details" and observe the cookie name and value.

Finally, here are some tips regarding where to find HTTP Response 
Splitting:
There are some more-likely-than-others places to look for HTTP 
Response Splitting. The first observation is that a lot of HTTP 
Response Splitting vulnerabilities are found in a redirection 
scenario (either a "true" HTTP redirection via a 3xx response with a 
Location header, or through the Refresh header in a 2xx response). So 
a server side script called "redirect" (or some other name containing 
"redir", or "goto", etc.) is a good place to start looking for HTTP 
Response Splitting. But even a normal script may be interesting, if 
one of its parameters happens to contain one of the strings "url", 
"redir", "to", and so forth.
Lastly, a lot of applications use redirection during the login 
process. The typical scenario is an anonymous user that tries to 
browse into an area which is login protected ("the restricted area"). 
The user is then sent to the login form with a parameter for the form 
containing the URL for the restricted area. Upon a successful login, 
the login script redirects the user back to the URL provided (which 
is supposed to be the restricted area) - and that's where a lot of 
HTTP Response Splitting vulnerabilities are found.

Good luck!
-Amit