607613 - HttpOnly cookies flushed by non-HttpOnly cookies (useful for session fixation)

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect, P3)

Description

[Pierre Ernst]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101012 Firefox/3.6.11 ( .NET CLR 3.5.30729)

When a server sets a cookie on a browser with the HttpOnly attribute, the cookie cannot be accessed via the DOM (document.cookie). This is an additional protection, in case there is an existing XSS vulnerability in the web application allowing an attacker to inject JavaScript code. This malicious JavaScript code could:
1.Send the value of a sessionId cookie to a foreign domain controlled by the attacker. The attacker is then able to hijack the session.
2.Overwrite a sessionId cookie with a value known by the attacker to perform a session fixation.
These two scenarios are normally prevented by the browser if the HttpOnly cookie attribute is used. Except that the latter attack can still be carried out with Firefox using a method detailed here.

Reproducible: Always

Steps to Reproduce:
1. The server sets a cookie (pierre=ernst) with the httpOnly attribute
<?php
setcookie('pierre', 'ernst', 0, '/', 'example.com', false, true);
?>

2. The newly set cookie is not accessible by the JavaScript code.

3. The victim visits a malicious page (XSS) containing JavaScript code which sets 100 different cookies. Eventually, the JavaScript code sets our 'pierre' cookie to 'overwritten'.
for (i=0; i<100; i++) {
    	  document.cookie="overflow" + i + "="+i+";domain=example.com;path=/";
        }
document.cookie="pierre=overwritten;domain=example.com;path=/";

4. A 'classic' session fixation can be performed. The attacker has set the 'pierre' cookie to the known value 'overwritten'.

Comment 1

[Pierre Ernst]

Attachment: files

Comment 2

[Daniel Veditz [:dveditz]]

I've actually been talking with security researchers during the summer conference circuit about this and related problems. Of course HTTPOnly isn't in any specification or RFC, it's a de-facto standard that Microsoft introduced and others copied. Is it better to have cross-browser consistency, or try to incrementally improve the behavior?

On the theory that a legit site won't have that many HTTPOnly cookies we could add checks such that regular cookies cannot cause HTTPOnly cookies to be flushed. Of course a MITM could still mess with your cookies, but that's what SSL is for. An evil site could flush all your non-HTTPOnly cookies and prevent the page from being able to set any cookies at all, but if the server is evil then you probably should worry about things other than session fixation.

I'm going to un-hide the bug because this is a known issue inherent to the (lack of) specification, but it's probably worth fixing.

Successful attack requires an XSS flaw on the site which is already bad news for the user.

Comment 3

[Michael Coates [:mcoates] (acct no longer active)]

(In reply to comment #2)
> Of course a MITM could still mess with your cookies, but that's what
> SSL is for. 
Something to keep in mind.
A MITM can flush all of your cookies even if SSL is in use (and if cookies are marked SECURE or HTTPOnly).

http://michael-coates.blogspot.com/2010/01/cookie-forcing-trust-your-cookies-no.html

Comment 4

[Adam Barth]

There now is a specification for cookies (including HttpOnly), which is finishing up the IETF process:

http://tools.ietf.org/html/draft-ietf-httpstate-cookie

I recommend closing this issue as WONTFIX.  This is just the way cookies work.  There's no way to provide security in this case anyway.  Trying to do something positive here just increases complexity without a tangible security benefit.

Comment 5

[Johnny Stenback (:jst)]

Dan, this sounds like WONTFIX to me, but I'll let you decide. Either way, not a blocker.

Comment 6

[[e-mail]]

Reassigning to nobody. If anyone wants to work on this, feel free!

Comment 8

[Daniel Veditz [:dveditz]]

updated link for httpstate spec that shows eventual rfc number:
http://www.rfc-editor.org/rfc/rfc6265.txt

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 11

[Andrea Marchesini [:baku]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=607613#c5