Paid Advertising
web application security lab


I’m happy to announce that Microsoft has released MS08-069 today. It’s got a lot of changes in it, but one in particular that I’ve been tracking for about a year now. MSXML has made a change so that HTTPOnly cookies cannot be read by XMLHTTPRequest within IE. Why is that good? It makes it so that JavaScript can no longer steal cookies that try to protect themselves. That’s a good thing.

It might seem like a big thing that that was even possible, but really it’s not as bad as it sounds, making this issue a lower priority in my mind. Cookies are rarely sent from the server to the client on every request and typically do require some information to be sent (like a username and password) before the Set-Cookie header is sent. So XMLHTTPRequest was really only useful for stealing cookies if the Set-Cookie header was sent on every request. Maybe there are some sites out there that do that, but it’s not that common. Either way, I’m glad MS got around to fixing it.

Meanwhile, the other browser that has implemented it of note is Firefox, and I hear rumors that they too are fixing this problem although I’m not sure on the timeframe there. So good news all around for HTTPOnly - the little non-standard cookie directive that could, and one of the few practical defenses against credential theft in the face of XSS.

13 Responses to “HTTPOnly Fix In MSXML”

  1. Sam Says:

    Glad to see some browsers are stepping up and fixing the issue.

  2. Wladimir Palant Says:

    The relevant Firefox bug is - it is going to land as soon as the tree reopens after Firefox 3.1 Beta 2. Note that after much back and forth the decision was to go with my original solution and make *all* Set-Cookie headers inaccessible to XMLHttpRequest. Better safe than sorry, too many things can go wrong with header value parsing.

  3. Jim Manico Says:

    I cannot confirm this fix on Vista sp1 7.0.5730.13 using the OWASP Webgoat HTTPOnly lab. Is this XO only?

  4. Jim Manico Says:

    I cannot confirm this fix on Vista SP1 - IE7.0.5730.13 using the OWASP Webgoat HTTPOnly lab - nor can I confirm this fix using Is this XP only?

  5. donwalrus Says:

    Granted, although this *seems* like an asinine, stupid, basic fix, it’s about time…think about how long the TRACE method has been able to do the same shite….and I see it all the time…the HTTPOnly directive simply needs to be in place on more than just the basic HTTP level…

    good post and thanks for the update!

  6. Jim Manico Says:

    Can anyone confirm how deep this bug fix is, for example, will it stop access to set-cookie and set-cookie2? Can anyone confirm that this bug fix is NOT working in Vista, even after installing MS08-069?

  7. Jim Manico Says:

    Ah, the error was with the Webgoat HTTPOnly test code, my bad.

    Robert, would you object to adding a set-cookie2 test to please?

  8. Jim Manico Says:

    Robert - thanks for adding a test for set-cookie2 - *** please note that the new IE patch does NOT protect against HTTPOnly cookie exposure for the set-cookie2 call *** - which the FireFox patch for 3.1/2 promises to fix -

    Also, thanks for letting MS know about this error. The weakness of blacklist filtering strikes again….

  9. Wladimir Palant Says:

    Note that Firefox time planning changed slightly, this fix will now be in Firefox 3.1 Beta 2.

  10. RSnake Says:

    And just to clarify, set-cookie2 is not supported at all by IE, but I don’t think it’s supported by Firefox either, unless I’m mistaken. Either way, it’s not a cookie standard that is used widely, by any means.

  11. Jim Manico Says:


    Firefox + IE 6/7 does not support set-cookie2

    FireFox 4 might support it.
    Opera apparently supports Set-Cookie2, as of 2007-08-25 or earlier

  12. Jeremy Says:

    I guess that spells the end of “DOM Based Cross Site Scripting” attack vector on IE.

  13. Thor Larholm Says:

    Jeremy, that might be a bit of an oversimplification ;-)