WebApp Sec mailing list archives
Re: "Divide and Conquer" - cross site response header tampering, cookie manipulation, and session fixation
From: Charlie Cano <ccano () magnifire com>
Date: 19 Mar 2004 21:11:17 -0000
In-Reply-To: <404B0134.3090701 () sanctuminc com> Hello, I just read Amit's paper, and found these discussions interesting. It seems, however, (as Jeremiah noted) that this vulnerability requires user-provided values to be inserted into HTTP Headers by the server. With an application firewall that understands the application and has a good security policy in place, this shouldn't be a threat. For example, MagniFire's TrafficShield application firewall uses a positive security model, so any parameter values that a malicious user tried to enter would be blocked by the firewall as invalid. So long as all user parameters are validated prior to hitting the webserver, these attacks are pretected against. Are there other scenarios that I missed? Thanks, Charlie
Received: (qmail 1750 invoked from network); 7 Mar 2004 12:30:22 -0000 Received: from outgoing2.securityfocus.com (205.206.231.26) by mail.securityfocus.com with SMTP; 7 Mar 2004 12:30:22 -0000 Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19]) by outgoing2.securityfocus.com (Postfix) with QMQP id CE2C290172; Sun, 7 Mar 2004 01:03:55 -0700 (MST) Mailing-List: contact webappsec-help () securityfocus com; run by ezmlm Precedence: bulk List-Id: <webappsec.list-id.securityfocus.com> List-Post: <mailto:webappsec () securityfocus com> List-Help: <mailto:webappsec-help () securityfocus com> List-Unsubscribe: <mailto:webappsec-unsubscribe () securityfocus com> List-Subscribe: <mailto:webappsec-subscribe () securityfocus com> Delivered-To: mailing list webappsec () securityfocus com Delivered-To: moderator for webappsec () securityfocus com Received: (qmail 25011 invoked from network); 7 Mar 2004 04:44:51 -0000 Message-ID: <404B0134.3090701 () sanctuminc com> Date: Sun, 07 Mar 2004 13:02:12 +0200 From: Amit Klein <amit.klein () sanctuminc com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: peterw () usa net Cc: jeremiah () whitehatsec com, webappsec () securityfocus com, bugtraq () securityfocus com Subject: RE: "Divide and Conquer" - cross site response header tampering, cookie manipulation, and session fixation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, Thanks for your message. I would like to make a distinction here. The attack I described, HTTP Response Splitting (or Divide and Conquer), is mostly focused on crafting an entire new HTTP response message. The direction described below is manipulation of the HTTP response in such way that a new header is added, but not an entire new response message. This concept is mentioned in my paper, under related work, where I explain the difference and provide a link to the paper "CRLF injection" by Ulf Harnhammer (http://www.securityfocus.com/archive/1/271515). In Ulf's paper, the idea of HTTP response manipulation (in the context of a *single* response message), and particularly of injecting a Set-Cookie header, is mentioned: HTTP defines a "Location:" header for redirecting to another URL, and a "Set-Cookie:" header to set cookies. By embedding CR and LF characters in user input, web scripts can be fooled into setting a cookie from their own web server while redirecting to another site. If the script constructs the redirect with a "Location: $url\015\012" string, and the $url string is not checked for CR and LF characters, we can redirect to a site while setting a cookie by giving $url the value "http://www.kuro5hin.org/\015\012Set-Cookie: evil=natas". If the cookie contains important data and one user can save URL's that another user will be redirected to, this can be serious. So unfortunately, I cannot take the credit for this - it all goes to Ulf Harnhammer. But it's a good thing that this whole subject of influencing the HTTP response re-surfaces, and I am glad to take part in it and to expand it ;-) Thanks, -Amit PS - one (minor) result of the paper is indeed an HTTP response manipulation in a single response message context. This is the case with the ASP.NET 1.1 anti-XSS pattern bypassing (in case of being able to inject data into a Set-Cookie header). -----Original Message----- From: Peter Watkins [mailto:peterw () usa net] Sent: Saturday, March 06, 2004 00:51 To: Jeremiah Grossman Cc: webappsec () securityfocus com; bugtraq () securityfocus com; Amit Klein Subject: 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_testHere 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
Current thread:
- Re: "Divide and Conquer" - cross site response header tampering, cookie manipulation, and session fixation Charlie Cano (Mar 19)