Paid Advertising
web application security lab

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 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.

13 Responses to “Firefox Implements httpOnly And is Vulnerable to XMLHTTPRequest”

  1. Andy Steingruebl Says:

    You always have to rain on the parade don’t you :)

  2. Giorgio Maone Says:

    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) {}

  3. RSnake Says:

    @Andy - hahah, where would you be without me brightening your day?

    @Giorgio - thank you, fixed.

  4. MikeA Says:

    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 - (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.

  5. kuza55 Says:

    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.

  6. hackathology Says:

    wow, i learnt quite some stuff on this post.

  7. sapphirecat Says:

    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.

  8. Jesse Ruderman Says:

    Here’s the bug number:

  9. Andrei Rinea Says:

    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.

  10. Jim Manico Says:

    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.

  11. Jim Manico Says:

    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!

  12. dt Says:

    Looks like the problem is finally fixed in Firefox 3.1

  13. Andrei Rinea Says:

    ASP.NET, JSP, JSF etc. will **NOT** “send a set-cookie with the session id in every response after proper authentication”.