[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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