Cookie forcing

It's time to write some coherent details about "cookie forcing", which is the name I've given for a new way to attempt to break into secure https sessions. This is surfjacking to the max - attacks an active MITM (man-in-the-middle) can attempt against an https application that follows best practices like marking its cookies secure; avoiding XSS and XSRF; etc.

Cookie forcing relies on slightly broken browser behaviour. Namely, an http response can set, overwrite or delete cookies used by an https session. This is a minor violation of https session integrity that can have significant consequences. Unfortunately, the cookie model works this way by specification and the addition of the Secure flag did not clean this up.

This means that every cookie value used by https applications could be malicious. This is somewhat counter-intuitive for developers of https-only apps, so it's understandable that vulnerabilities result from too much trust here. Looking at specific classes of vulnerability that can result from this, we have:

• XSS
• XSRF
• Login XSRF
• DoS
• Logic abuse

Regarding XSS, any trust of the cookie value to be properly escaped (before e.g. pasting it into the DOM or document.write) is a vulnerability. Properly escaping the cookie value on write and relying on https for integrity is not sufficient, unfortunately.

There's another increasingly common application construct which cookie forcing can abuse to cause XSS. An increasing number of frameworks are writing JSON into cookie values for fast deserialization of complex data types. Some of these frameworks read the values back in using the fast option of e.g. eval('var x = ' + getCookieValue('STATE')). I'm sure you can see the pitfall here.

Regarding XSRF, there is a certain type of XSRF protection that can be subverted by cookie forcing. If the XSRF protection is a simple comparison between a URL parameter value and a cookie value, the active MITM attacker can now fake both of these. The mitigation is to ensure that the value is cryptographically attached to the current user's session via e.g. an HMAC.

Regarding login XSRF, I recommend the very recent paper by Adam Barth, Collin Jackson and John Mitchell which covers this topic nicely. These guys are great - they don't just moan about breakage in the browsers, they work to fix it up too. See the "Cookie-Integrity" header suggestion. In the absence of this header, one possible mitigation is to randomize the name of the session cookie. But that's going to a somewhat extreme measure to work around a browser deficiency. I'm not going to recommend every web app does something complex, when the fix should be driven by the browsers. Also note that logout XSRF will be near impossible to fix; an attacker can just spray cookies into a browser until it drops the session cookie.

Regarding DoS and logic abuse, there is the possibility to mess with any cookies an https app uses, to try and make is misbehave when it encounters unexpected values. The mitigation is to sign any sensitive cookies (tying to the current user, preferably current session).

Cookie forcing works very well in conjunction with my previous post regarding browser background http requests. In such an attack, a victim won't see anything untoward. The redirections all happen behind the scenes and do not change the URL status bar.

Remember that this attack is only relevant against https applications without any more obvious vulnerabilities. You need an active MITM capability (e.g. public wireless) to attempt it. Any applications without https support are already ruined against such a threat model.

Credit to Filipe Almeida for being about two years ahead of the rest of the web app security community, as usual. The XSRF issue was his originally, and a long time ago. More recently, there appears to have been an independent discovery by Collin Jackson and friends at Stanford.

Owning the paranoid: browser background traffic

When I talk to a lot of security researchers or paranoid types, it's very common to hear them describe how they very carefully access their bank account or personal GMail etc. Generally, the model used is to launch a separate browser instance, and navigate straight to an https bookmark. The session remains single-window, single-tab. It's a powerful model; the intent is to eliminate the chance of another (http) tab being a vector for owning the browser, or more likely abusing a cross-domain flaw in the browser or bank's web application.

Attacking this browsing model was one of the key demos in my PacSec presentation.

Whether you know it or like it or not, your browser is likely engaging in a flurry of behind-the-scenes plain http requests. Some examples are:

• Safebrowsing updates
• OCSP or other certificate related requests
• Updating RSS feeds

Before going on to what a MITM attacker can do here, it's very worth mentioning the mitigation that I found. It seems to work well on the browsers I tested. If you set your http proxy (and all protocols other than https, why not) to localhost:1, then this unwanted plain http traffic will not go out on the network. The browsers seem to honour the proxy setting even for internally-initiated requests which is nice. It's not entirely clear that blocking OCSP requests in this way is ideal, but it's better than the alternatives.

So what evil can the MITM attacker do with these plain http requests? The good news is that the requests that need to be are signed (Safebrowsing and OCSP). Interestingly, a failure talking OCSP during an https initiation does not prevent the connection, but that's a separate discussion.

Specific useful attacks include:

• Attacking the exposed HTTP protocol attack surface
• Replying with a 302 redirect in order to exploit surfjacking
• Replying with a 302 redirect followed by a Set-Cookie to exploit cookie forcing

As you can see, it's an interesting result that this paranoid browsing model does not protect you from surfjacking attacks where you think it might have. Particularly so because a lot of financial web sites neglect to mark their cookies Secure.

Cookie forcing is a great advanced way for an MITM to break into https web apps that are not vulnerable to surfjacking (or XSS, XSRF, XSSI, the usual stuff etc). I will detail this new attack class and its opportunities in a subsequent post. Also see Billy's nice write up on mixed content http script loading for another under-appreciated attack against https web apps.

Closing questions that could lead to future research include:

• Do Firefox / Opera / other browsers have robust OCSP response parsers?
• What can you do with evil / malformed XML responses to RSS updates?
• What about replying to a background request with an unexpected MIME type - does that expand the attack surface?
• What about other interesting or unexpected HTTP headers?

E4X and a Firefox XML injection bug

Up-front credit to my colleagues Filipe Almeida and Michal Zalewski who led the way in E4X security research.

If you haven't heard of E4X, or don't know why Firefox's E4X support should scare you, please consider reading this article.

I've just released details for a recently fixed Firefox XML injection bug. It's one of those bugs that is in search of a good exploitation opportunity. Currently, the known impact is negligible, but I'm throwing it out in case anyone has better ideas than I do. It feels like the interaction of this bug and E4X should be fruitful but perhaps not:

http://scary.beasts.org/security/CESA-2008-010.html

Firefox cross-domain image theft... and the "302 redirect trick"

Here's the first bug with full details from my PacSec presentation. It's fixed in the recent Firefox 2.0.0.18 update. Firefox 3 was never vulnerable. In a nutshell, decent modern browsers permit you to read the pixels from an image by rendering images to a <canvas> and calling the Javascript APIs getImageData or toDataUrl. Therefore, cross-domain checks are required on the usage of these APIs. In Firefox, these checks were present but did not cater for the "302 redirect trick" properly.

So what is the "302 redirect trick"? It is where a malicious web page accesses a remote resource by referring to a local same-domain URL which hits the remote resource via an HTTP redirect. If the attacker is lucky, the browser is fooled into believing the remote resource is actually a local resource. And then theft is trivial.

The "302 redirect trick" has appeared many times in the past. It will undoubtedly lead to more vulnerabilities (I have two pending in fact). My personal past favourite was from my Google colleague Martin Straka, who noticed that 302 redirect targets leaked into the DOM when loading stylesheets.

The "302 redirect trick" works particularly well in cross-domain areas where the cross-domain nature of requests used to be unimportant. In this example of images, it has always been accepted that existence (or not) and width / height leaks cross-domain. However, getting the domain right became critical when the image data itself became accessible. Contract with iframes, where getting the domain right has always been critical. Browsers tend to not suffer vulnerabilities when loading iframes via a redirect.

Full details including demo attack code are in the advisory:

http://scary.beasts.org/security/CESA-2008-009.html

PacSec presentation

My recent PacSec presentation (with Billy Rios), entitled "Cross-domain leakiness", is now online.
You can view it via this link.

There's a new way to attack SSL-enabled web apps in there ("Cookie Forcing"); a bunch of serious browser cross-domain thefts (many not yet disclosed); and attacks against the paranoid one window / one tab browsing model.

The slides by themselves are a little sketchy on detail. So over the next few days, time permitting, I'll write individual blog posts summarizing these areas. I will also blog details about the serious cross-domain thefts as and when the browser vendors fix them.