HTTPOnly Fix In MSXML
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.
November 11th, 2008 at 3:46 pm
Glad to see some browsers are stepping up and fixing the issue.
November 12th, 2008 at 2:16 am
The relevant Firefox bug is https://bugzilla.mozilla.org/show_bug.cgi?id=380418 - 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.
November 12th, 2008 at 2:26 pm
I cannot confirm this fix on Vista sp1 7.0.5730.13 using the OWASP Webgoat HTTPOnly lab. Is this XO only?
November 12th, 2008 at 2:34 pm
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 http://ha.ckers.org/httponly.cgi. Is this XP only?
November 12th, 2008 at 10:48 pm
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!
November 13th, 2008 at 12:26 pm
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?
November 13th, 2008 at 4:38 pm
Ah, the error was with the Webgoat HTTPOnly test code, my bad.
Robert, would you object to adding a set-cookie2 test to http://ha.ckers.org/httponly.cgi please?
November 14th, 2008 at 1:37 pm
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 - https://bugzilla.mozilla.org/show_bug.cgi?id=380418
Also, thanks for letting MS know about this error. The weakness of blacklist filtering strikes again….
November 14th, 2008 at 2:14 pm
Note that Firefox time planning changed slightly, this fix will now be in Firefox 3.1 Beta 2.
November 14th, 2008 at 2:49 pm
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.
November 14th, 2008 at 3:14 pm
Per https://bugzilla.mozilla.org/show_bug.cgi?id=208985
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
November 21st, 2008 at 5:02 pm
I guess that spells the end of “DOM Based Cross Site Scripting” attack vector on IE.
December 26th, 2008 at 2:55 am
Jeremy, that might be a bit of an oversimplification