[NEWS] Detecting and Testing HTTP Response Splitting Using Browser Cookies Alert

From: SecuriTeam (support_at_securiteam.com)
Date: 10/18/04

  • Next message: SecuriTeam: "[REVS] GDI+ JPEG Exploit Mutations Can Bypass Antivirus Tests" 
    To: list@securiteam.com
Date: 18 Oct 2004 14:49:43 +0200

    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.

  • Next message: SecuriTeam: "[REVS] GDI+ JPEG Exploit Mutations Can Bypass Antivirus Tests"

    Relevant Pages