The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Detecting and Testing HTTP Response Splitting Using Browser Cookies Alert
------------------------------------------------------------------------
SUMMARY
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
headers 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.
Presented below is a method for detecting and testing HTTP Response
splitting using specially injected cookies.
DETAILS
There are ways to test HTTP Response Splitting, e.g. using raw interface
TCP/HTTP tools, or by using "HTTP Response Splitting" - aware web
application scanners. This write-up is all about using the browser to
detect the success (or failure) of HTTP Response Splitting.
The method present here has the following benefits:
* It works both for HTTP 2xx responses and HTTP 3xx responses.
* 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 over 90% of the 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> Divide
and Conquer- cross site response header tampering, cookie manipulation,
and session fixation).
Testing Method:
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 injected parameter):
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.
ADDITIONAL INFORMATION
The information has been provided by <mailto:aksecurity@hotpop.com> Amit
Klein (AKsecurity).
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
