Re: "Divide and Conquer" - cross site response header tampering, cookie manipulation, and session fixation

From: Peter Watkins (peterw_at_usa.net)
Date: 03/05/04

  • Next message: George Swentek: "Antivir for Freebsd doesn't work on 5.X" 
    Date: Fri, 05 Mar 2004 17:51:16 -0500
To: Jeremiah Grossman <jeremiah@whitehatsec.com>

    Jeremiah Grossman wrote:

    > This technique builds upon the scenario that user-supplied data is
    > inserted into the headers of an HTTP response message.

    > GET /redirect%0aX-Test:%20foo_test HTTP/1.0
    >
    > HTTP/1.1 302 Found
    > Date: Fri, 05 Mar 2004 16:41:31 GMT
    > Server: Apache/1.3.29
    > Location: http://foo.com/redirect
    > X-Test-Header: foo_test

    > Here are the vulnerability requirements.
    > 1) User-supplied data is inserted in the headers of an HTTP Response
    > 2) User input is unescaped.
    >
    > The results could have the ability to poison the cache in an
    > intermediary device or a web browser.

    I think it can be more interesting than that. A vulnerable web server
    could be coaxed into doing things like erase or change cookies in a
    victim's browser -- shades of CSRF & XSS. Consider an email with this
    image tag

    <img
    src="https://vulnerable.com/app?x=%0d%0aSet-Cookie:%20UID=victim%0d%0a"
    height=0 width=0 style="visibility: hidden"/>

    If a victim opened a page with such an "invisible" image and did not
    have cookie warnings enabled, such a tag could make the
    divide-and-conquer (DAC) vulnerable /app on vulnerable.com set (or
    change the value of) the victim's UID cookie for vulnerable.com.

    Such a cookie-fixing attack would have nothing to do with any
    proxy/cache servers, and would not face the timing challenges that
    Sanctum outlines in its paper.

    This could be used as a DoS/annoyance (change the UID to something
    invalid, so the victim cannot maintain their session) or could be used
    to facilitate something like session fixation attacks, as described in
    Dec 2002 by Acros (attacker gets a sessionid, uses DAC vuln to put that
    cookie on the victim's browser, then is able to cohabitate the victim's
    session on the targeted site).

    With regards to session fixation and app servers that use "typical"
    sessionid cookie, it's worth noting that likely *any* site within the
    same second-level domain could set a cookie that would be recognized by
    other sites in that domain, e.g. a DAC-vulnerable app on the http site
    at "legacy.example.com" could set an ".example.com" cookie that would be
    presented and honored by the https site at "banking.example.com".

    To me, DAC seems like a twist on XSS. XSS discussions focused largely on
    embedding content within the body of an object (HTML page); with DAC the
    concern is Response headers, completely outside the message body. Nice
    work, Amit.

    -Peter

  • Next message: George Swentek: "Antivir for Freebsd doesn't work on 5.X"

    Relevant Pages

    • Re: CURL and $_SESSION problem
      ... > needed to keep the session open is the cookie with the session id. ... from a remote site? ... > not forgetting the headers, ...
      (alt.php)
    • Re: CURL and $_SESSION problem
      ... > needed to keep the session open is the cookie with the session id. ... from a remote site? ... > not forgetting the headers, ...
      (comp.lang.php)
    • Re: function within echo"";
      ... session, cookie and header must ALWAYS be sent before any output, so here are some example on what you shouldn't do: ... <?PHP ... - store all output into a variable say $output, and when all headers, cookies, sessions are sent and all the output has been stored to the variable, first then do a: ...
      (alt.php)
    • Re: Disabling session cookies for a single script
      ... > FDF output (when the clients run IE) doesn't like to have a session ... > cookie included in the headers. ... "Set-Cookie:" headers, ...
      (alt.php)
    • Re: Sessions vs Cookies
      ... There is a session cookie which simply allows the server to identify the client and retrieve relevant session data for it. ... If cookies can be read or forged, it makes little odds whether you have the master key or all the little keys,. ... Suppose you only send the PHPSESSID: Now you cannot change a thing on the server, even if you have the 'master key'. ...
      (comp.lang.php)