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.