Bugzilla@Mozilla – Bug 458248
XMLHttpRequest 302 response disclosure
Last modified: 2009-02-26 20:26:33 PST
Summon comment box
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008052912 Firefox/3.0 A XMLHttpRequest which hits a 302 to another domain returns the 302 headers and body. In single-signon environments these headers might contain sensitive url parameters. The XMLHttpRequest originates from source domain, but the SSO state could be protected with HttpOnly. Returning the 302 headers allows for using the SSO state as an oracle to mints access tokens for other domains. All other browsers I tested do not return such 302 responses to the script. Reproducible: Always Steps to Reproduce: 1.Setup a server that has a 302 to another domain 2.Issue XHR, in domain, to the url that will 302 3.Observe the 302 headers and body are available to the XHR issuer Actual Results: 302 headers and body, with location being a different protocol:host:port/path?params Expected Results: Security exception or no data. Other browsers return status 0 and no content. Or throw security exceptions. Since other browsers do not return data, it is unlikely that tightening this up will break existing applications. As for precedents regarding fixing this type of bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=397427
So we have server at example.org, running XHR to example.org, which redirects to example.com ?
yes, for instance. And the XHR being XSS injected. The XSS couldn't steal SSO cookie directly (httponly) but can still use it as oracle. A 302 might contain data intended for the other domain only.
XS-XHR might have "fixed" this.
> XS-XHR might have "fixed" this. That doesn't help FF3. I bet this affects FF2 as well.
Created attachment 348717 [details] [review] Branch fix Got r/sr from mrbkap
Comment on attachment 348717 [details] [review] Branch fix approved for 1.8.1.19 and 1.9.0.5, a=dveditz for release-drivers
Checked in
Actually, I think this might not be fixed on trunk, even with XS-XHR support :(
I'm a little confused about the 1.8 patch here (haven't looked at the rest). What's the point of setting mDenyResponseDataAccess _after_ the return statement? Note that that's not what the patch in the bug has, but it's what I see at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsXMLHttpRequest.cpp&rev=1.156.2.20&mark=2054-2057#2030 As in, is this even fixed on 1.8 branch?
Aww crap, it is not :(
Created attachment 350230 [details] [review] Branch fix fix
Comment on attachment 350230 [details] [review] Branch fix fix Duh :)
Comment on attachment 350230 [details] [review] Branch fix fix Approved for 1.8.1.19. a=ss Please land on the 1.8 branch as soon as possible.
Landed on 1.8 branch. Thanks for noticing bz!
No problem. Now if only I could figure out what might have changed on branch to cause the XHR issues this guy in m.d.t.network is seeing.... This certainly wasn't it. ;) I'm just really glad we have unit tests on 1.9.0 and trunk.
Verified for 1.9.0 with the unit tests. I don't have the infrastructure to do the 302 responses to manually test this for 1.8.1. Can someone offer a way to verify that this is really fixed for 1.8.1?
Created attachment 351892 [details] [review] 1.8.0 branch patch
Comment on attachment 351892 [details] [review] 1.8.0 branch patch Can you please check the backport?
Comment on attachment 351892 [details] [review] 1.8.0 branch patch a=asac for 1.8.0
Marking as regression since this has been fixed on branch, but not yet on trunk
Jonas, does this need another patch for trunk? Or, do we just need to land?
Fixed in bug 479521