Recently I have been investigating how cookies are treated by various browsers - specifically cookies set with the 'HTTPOnly' attribute. I've found a couple of cases where the browser's behaviour leads to interesting conditions, such as locking users out of an application - both of these issues have been identified in WebKit browsers Safari and Chrome.
This has been covered in the past by Michal Zalewski as part of the Browser Security Handbook, however some of the conditions appear to have changed, which potentially open new areas of attack. The particular areas I'm talking about are 'Overwriting cookies', 'Problems with conflict resolution' and mainly, 'Problems with "protected" cookie clobbering' on this page.
I have raised both of these issues as bugs / 'unusual behaviour' with Apple and Google, both of which have decided that it's not a security issue - so I'm documenting it here in case anyone else comes across or is interested in this behaviour. This behaviour eases the exploitation of session fixation vulnerabilities in web applications. While every webapp that doesn't set a new cookie upon authentication/privilege change is vulnerable to session fixation, the exploitability of the vulnerability depends on whether the attacker can control the cookie value that the web application will use as the session token - and this cookie-juggling behaviour allows the attacker to control said value.
Preconditions for this issue to be exploited are:
The following methods can be used to create a new cookie in the Chrome cookie-store, with the same name as an existing cookie - even if the existing cookie was set with the HTTPOnly tag:
In the last instance, if the cookie has a different domain (e.g. .testvhost.com instead of testvhost.com), then the same behaviour with the juggling of cookie priority will occur. Of course if you control the Set-Cookie statement you have control of the cookie anyhow, I just thought it would be helpful to note that it can still be a contributor to Chrome's behaviour.
This is a quirk with how WebKit treats multiple cookies with the same name. My expected behaviour is that Chrome would:
- only ever send one cookie, or
- always send all cookies in the same order/priority, and
- not to choose which cookie to send based on which cookie was most recently set, regardless of the method it was set in.
If the server-set (valid) cookie has a domain specified, the attack will only work until the browser receives a new cookie from the server. This is because the cookie is overwritten, rather than shuffled further down the Cookie: header. While this behaviour does not allow a malicious actor to access an existing Cookie, it does allow the actor to more easily exploit a session fixation vulnerability or prevent a user from accessing a web application.
I have included a couple of scenarios below:
Scenario A - Cookie Overwrite:
1. Server sets a cookie with a domain flag and HTTPOnly, e.g.: "sessionid=12345; path=/; domain=.apple.com; httponly"
3. Next request sent by the browser will send the sessionid of 54321. If the server sets a new cookie after this, the sessionid will then take that value.
Scenario B - Cookie Added With Higher Preference:
1. Server sets a cookie without a domain specified, with HTTPOnly, e.g.: "mycook=setbyserver; path=/; httponly"
3. All further requests sent by the browser will send the sessionid of setbyhtml. If the server sets a new cookie after this, the sessionid will not be changed from setbyhtml. Users could be locked out of an application (until cookies are cleared/browser is restarted) by using this technique.
In conclusion.. I can understand the browser vendors' choices not to treat this behaviour as a security vulnerability, but believe that this behaviour eases exploitation of issues in vulnerable web applications. Of specific concern is that if targetsite.com has a cookie-based session fixation vulnerability, then if subdomain.targetsite.com has an XSS issue, targetsite.com's "protected" HTTPOnly cookie can be overwritten. An interesting condition, anyway.