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.
Sounds like a greasemonkey script to me. :)
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.
Will the introduction of Unified Storage in Firefox 2 mean that this will be implemented?
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…
“…in Internet Explorer 6Service Pack 1 (SP1).”
I never heard IE service pack. I think it’s XP SP1.
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?
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?
Dao’s right about the first bit, iframe XXSing works by doing something like this:
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.
I wrote an article on this on the below link it includes PHP support for HttpOnly, and information from this thread.
I just tested this, it seems to be defeated by
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).
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