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:
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.
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
[ reply ]