Firefox Implements httpOnly And is Vulnerable to XMLHTTPRequest
I saw a few different people mention over the last few days that httpOnly has been added to Firefox 2.0.0.5. Very exciting stuff - as this has long been missing for over two years. There are some major pros and cons when using httpOnly on cookies. The pros are that httpOnly cookies aren’t visible in JavaScript space using document.cookie and that makes XSS much more difficult when using it in context of credential theft. The cons are that it doesn’t work in all browsers and in some browsers, like WebTV and IE5.5 on Mac it can actually cause the page to fail to load. Granted the user base on those browsers is pretty minimal but that may be a show stopper for some people.
The only problem I see with using this as protection against credential theft is that the cookies are still visible using XMLHTTPRequest. If you look at Alex’s example, it looks secure because the cookie is not visible. But if you look at this example you can see that using XMLHTTPRequest you can still get access to the cookie by looking at the headers. This has been one of those long standing problems with httpOnly, but it does raise the barrier by shutting down the most obvious way of getting at the cookies, using document.cookie.
July 19th, 2007 at 9:35 am
You always have to rain on the parade don’t you
July 19th, 2007 at 9:49 am
OK, we’re talking about the Firefox implementation here.
But since you included it, what about fixing the fall-back code for IE?
As it’s written now it throws an exception at line 5.
You can fix it with some try {} catch {} blocks:
try { req = new XMLHttpRequest(); } catch(e) {}
if (!req) try { req = new ActiveXObject(”Msxml2.XMLHTTP”); } catch(e) {}
if (!req) try { req = new ActiveXObject(”Microsoft.XMLHTTP”); } catch(e) {}
July 19th, 2007 at 2:19 pm
@Andy - hahah, where would you be without me brightening your day?
@Giorgio - thank you, fixed.
July 19th, 2007 at 4:58 pm
Nice to see that it’s *finally* been implemented in FF - seems that I’m starting to run out of things to rant about during my classes/public speaking - this and the Google cookie were faves of mine - http://googleblog.blogspot.com/2007/07/cookies-expiring-sooner-to-improve.html (not that the cookie thing will change anything, it’s just a different approach).
In any case, it’s just defence-in-depth. For one simple thing you get a little bit more protection from script-kiddies. Sure, it can be circumvented, but it might just be that one more thing that makes an attacker move on.
July 19th, 2007 at 5:52 pm
Well, as I said to ma1 in the comments on my post, I’m honestly surprised that they didn’t fix a bug that IE6 had, and was fairly well known.
But even if that is still the case, it isn’t a viable attack on most applications as most applications only send the set-cookie header once, and that is when people first login, not on any page which is being requested through the XHR object, and so there is no way to use that code against most apps.
July 21st, 2007 at 12:16 am
wow, i learnt quite some stuff on this post.
July 26th, 2007 at 5:39 am
@kuza55:
PHP’s built-in session handling is absolutely retarded, so it will send the session cookie every time you start a session. In fact, it will send the identical cookie multiple times in one response if you call session_start() multiple times in the code.
September 8th, 2007 at 3:12 pm
Here’s the bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=380418
September 21st, 2008 at 6:35 am
All nice and dandy but you can’t steal a session cookie this way.
Why? Simple :
The first request (for the page) will have a Set-Cookie header containing the Session cookie. The subsequent XMLHttpRequest from the page’s javascript code will be issued with that session cookie and the server WILL NOT send again a Set-Cookie for the session cookie.
Therefore session hijacking cannot be done this way as far as I can see.
Correct me if I’m wrong.
September 23rd, 2008 at 8:21 pm
Wrong Andrei - there are many server platforms that send a set-cookie with the session id in every response after proper authentication. However, ie8 patched this bug. FireFox is getting close to a resolution, too. https://bugzilla.mozilla.org/show_bug.cgi?id=380418
September 23rd, 2008 at 8:26 pm
As a side note, this bug has been fixed in current builds of IE8 - Go Bill, ie8 is the first browser to fix the XMLHttpRequest responce header HTTPONLY cookie leak! woot!
January 27th, 2009 at 4:56 pm
Looks like the problem is finally fixed in Firefox 3.1
February 10th, 2009 at 12:19 pm
ASP.NET, JSP, JSF etc. will **NOT** “send a set-cookie with the session id in every response after proper authentication”.