Comment on attachment 345336 [details] [diff] [review]
Patch also blocking Set-Cookie2 header
[Checkin: Comment 85]
>+	// Try reading headers in privileged context
>+	netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect UniversalBrowserRead");
>+	is(request.getResponseHeader("Set-Cookie"), "test", "Reading Set-Cookie response header in privileged context");
>+	is(request.getResponseHeader("Set-Cookie2"), "test2", "Reading Set-Cookie2 response header in privileged context");
>+	is(request.getResponseHeader("X-Dummy"), "test", "Reading X-Dummy response header in privileged context");
>+	ok(/\bSet-Cookie:/i.test(request.getAllResponseHeaders()), "Looking for Set-Cookie in all response headers in privileged context");
>+	ok(/\bSet-Cookie2:/i.test(request.getAllResponseHeaders()), "Looking for Set-Cookie2 in all response headers in privileged context");
>+	ok(/\bX-Dummy:/i.test(request.getAllResponseHeaders()), "Looking for X-Dummy in all response headers in privileged context");
>+	// Try reading headers in unprivileged context
>+	setTimeout(function() {
>+	  is(request.getResponseHeader("Set-Cookie"), null, "Reading Set-Cookie response header in unprivileged context");
>+	  is(request.getResponseHeader("Set-Cookie2"), null, "Reading Set-Cookie2 response header in unprivileged context");
>+	  is(request.getResponseHeader("X-Dummy"), "test", "Reading X-Dummy response header in unprivileged context");
>+	  ok(!/\bSet-Cookie:/i.test(request.getAllResponseHeaders()), "Looking for Set-Cookie in all response headers in unprivileged context");
>+	  ok(!/\bSet-Cookie2:/i.test(request.getAllResponseHeaders()), "Looking for Set-Cookie2 in all response headers in unprivileged context");
>+	  ok(/\bX-Dummy:/i.test(request.getAllResponseHeaders()), "Looking for X-Dummy in all response headers in unprivileged context");
>+	  SimpleTest.finish();
>+	}, 0);
Nit: If you first check that Set-Cookie is normally blocked, *then* call netscape.security.PrivilegeManager.enablePrivilege, and then check that you now can get to it, you won't have to mess with setting a timeout.
r/sr=me either way.

(In reply to comment #73)
> Supposedly, Microsoft fixed that issue in MS08-069 released today
> (http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx). "MSXML
> Header Request Vulnerability" describes a different issue however.
Does anyone know how they handle it? Do they just block the header, like the patch for this defect does, or do they filter out only httponly-cookies? (I don't have a MS-system available to test it myself...)

If you have a mixture of both "normal" and httponly cookies, do they only block the httponly ones, or do they block all of them?
Either way, I think we should try our solution due to its simplicity.

Comment on attachment 345336 [details] [diff] [review]
Patch also blocking Set-Cookie2 header
[Checkin: Comment 85]
Seems to me that we need to take this for b2 if we're going to take it at all...

Looks like IE's recent patch (http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx) now stops set-cookie exposure to HTTPOnly cookies via JavaScript - but not set-cookie2 HTTPOnly exposure. http://ha.ckers.org/httponly.cgi was updated to include set-cookie and set-cookie2 tests today, btw.

Note IE does not return a single Set-Cookie header. As such, getResponseHeader('Set-Cookie') now only returns the first non-httponly Set-Cookie header. But that probable made it simpler for them to just filter the httponly Set-Cookie headers.
Also note, combining Set-Cookie headers with a comma separator has issues with comma being a legal value in an individual Set-Cookie header.
I doubt there are useful apps out there that rely on being able to parse Set-Cookie headers from getAllResponseHeaders(). If there are, we might be breaking more of them by combining multiple Set-Cookie headers into a single one already.

committed attachment 355351 [details] [diff] [review] to MOZILLA_1_8_BRANCH:
Checking in content/base/src/nsXMLHttpRequest.cpp;
/cvsroot/mozilla/content/base/src/nsXMLHttpRequest.cpp,v  <--  nsXMLHttpRequest.cpp
new revision: 1.156.2.22; previous revision: 1.156.2.21
done

You are all champions! FireFox 3.0.0.6 is the first browser to truly offer complete and comprehensive HTTPOnly support! http://manicode.blogspot.com/2009/02/firefox-3006-httponly-champion.html
My hats off to you all, beer is on me!

Robert Hansen was not fond of the fact that ALL cookies were removed from the XHR response headers via JS access.  I'm not sure I agree, but felt it prudent to pass his thoughts your way. What do you think?
(from Robert Hansen re: The fact that all set-cookie/2 calls were removed from response headers) 
That's kind of a bug (or at minimum a bad feature).  XHR should allow any headers to be viewed that don't have the HTTPOnly flag.  Who knows, maybe some web developers use XMLHTTPRequest to read the cookie (which might contain something benign like last seen date) and use it to display it back on the page?  Now HTTPOnly breaks that functionality.  The last thing you want is people removing HTTPOnly to re-enable functionality that already worked.
Firefox overstepped the whole point of the security feature.  You don't start disabling random other things just because you disable one.  Think about it from a developer's perspective.  You're sitting in a conference room, and you're not that brilliant and you say, "I heard that if you use HTTPOnly sometimes you won't be able to read not HTTPOnly cookies."  And you less than brilliant developer friend says, "Whelp, I guess we had better not consider it, we need to read those cookies, by golly."  And henceforth you have lower adoption.
	HTTPOnly has had enough problems without introducing extremely hard to understand "features" (hard to understand unless you are intimately familiar with the tech).  Plus, I have been known to replay cookies using XHR before too, because I want the exact syntax (including path name and expiration), and not the slimmed down document.cookie version of the actual header.  It's not all that uncommon.  It would be a nightmare do debug if I didn't know that Firefox had done that (on a different cookie, no less).  I'd bet a dollar most developers wouldn't have a clue as to why it was happening.

Robert misunderstands, I believe.  We never show set-cookie in XHR results, regardless of whether there is an HTTPOnly cookie in the response or not, so use of HTTPOnly doesn't affect anything here.  Ergo, there's no reason to avoid it in favour of more functionality.
(That's my interpretation of the patch, at least, I haven't tested exhaustively.)

See #87 regarding how useful Set-Cookie response headers are. You can parse the non-httponly cookies from document.cookie more reliably. And spec says implementations are free to drop transient headers and security related like set-cookie are called out specifically. The current 3.0.6 behavior is just fine.

Re: comment 103 -- removing HttpOnly from your cookies will not bring the functionality back. That won't be a temptation. If we had hidden only headers with HTTPOnly cookies then developers *might* be tempted to remove that attribute. Developers might get pissed at us for our aggressive approach here, but it cannot be accused of discouraging adoption of HttpOnly since the functionality is gone whether or not you use it.
I've filed bug 476977 on enhancing the DOM with the additional cookie data that developers might be trying to get out of manually parsing headers from XHR.

(from Robert Hansen) 
I read the thread, and that makes more sense.  I thought XHR was disabling all because one cookie had HTTPOnly.  I didn’t realize it was independent of that feature.  That’s less bad.  Still, it’s going to cause some people to riot in the streets when they’re trying to get code to work regardless of how secure their cookies are, but at least it won’t harm HTTPOnly adoption, they’re correct.