Last Comment Bug 458248 - (CVE-2008-5506) XMLHttpRequest 302 response disclosure
: XMLHttpRequest 302 response disclosure
: fixed1.8.1.19, fixed1.9.1, regression, verified1.9.0.5
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: P2 normal (vote)
: mozilla1.9.1
Assigned To: Jonas Sicking (:sicking)
Depends on: 479521
  Show dependency treegraph
Reported: 2008-10-02 11:21 PDT by marius schilder
Modified: 2009-02-26 20:26 PST (History)
12 users (show)
jonas: blocking1.9.1+
dveditz: blocking1.9.0.5+
dveditz: wanted1.9.0.x+
dveditz: blocking1.8.1.19+
dveditz: wanted1.8.1.x+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Branch fix (8.69 KB, patch)
2008-11-17 22:08 PST, Jonas Sicking (:sicking)
jonas: review+
jonas: superreview+
dveditz: approval1.8.1.19+
dveditz: approval1.9.0.5+
Details | Diff | Review
Branch fix fix (981 bytes, patch)
2008-11-26 15:01 PST, Jonas Sicking (:sicking)
jst: review+
jst: superreview+
samuel.sidler+old: approval1.8.1.19+
Details | Diff | Review
1.8.0 branch patch (2.86 KB, patch)
2008-12-08 06:33 PST, Martin Stránský
jonas: review+
Details | Diff | Review

Description marius schilder 2008-10-02 11:21:01 PDT
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
Comment 1 Boris Zbarsky [:bz] 2008-10-02 11:39:15 PDT
So we have server at, running XHR to, which redirects to ?
Comment 2 marius schilder 2008-10-02 11:49:18 PDT
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.
Comment 3 Jonas Sicking (:sicking) 2008-10-02 12:08:11 PDT
XS-XHR might have "fixed" this.
Comment 4 Daniel Veditz [:dveditz] 2008-10-10 18:48:07 PDT
> XS-XHR might have "fixed" this.

That doesn't help FF3. I bet this affects FF2 as well.
Comment 5 Jonas Sicking (:sicking) 2008-11-17 22:08:43 PST
Created attachment 348717 [details] [diff] [review]
Branch fix

Got r/sr from mrbkap
Comment 6 Daniel Veditz [:dveditz] 2008-11-17 22:26:06 PST
Comment on attachment 348717 [details] [diff] [review]
Branch fix

approved for and, a=dveditz for release-drivers
Comment 7 Jonas Sicking (:sicking) 2008-11-18 19:34:38 PST
Checked in
Comment 8 Jonas Sicking (:sicking) 2008-11-19 12:19:16 PST
Actually, I think this might not be fixed on trunk, even with XS-XHR support :(
Comment 9 Boris Zbarsky [:bz] 2008-11-26 13:03:16 PST
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

As in, is this even fixed on 1.8 branch?
Comment 10 Jonas Sicking (:sicking) 2008-11-26 13:13:52 PST
Aww crap, it is not :(
Comment 11 Jonas Sicking (:sicking) 2008-11-26 15:01:27 PST
Created attachment 350230 [details] [diff] [review]
Branch fix fix
Comment 12 Johnny Stenback (:jst, 2008-11-26 15:02:07 PST
Comment on attachment 350230 [details] [diff] [review]
Branch fix fix

Duh :)
Comment 13 Samuel Sidler (old account; do not CC) 2008-11-26 15:22:20 PST
Comment on attachment 350230 [details] [diff] [review]
Branch fix fix

Approved for a=ss

Please land on the 1.8 branch as soon as possible.
Comment 14 Jonas Sicking (:sicking) 2008-11-26 16:00:38 PST
Landed on 1.8 branch.

Thanks for noticing bz!
Comment 15 Boris Zbarsky [:bz] 2008-11-26 16:05:55 PST
No problem.  Now if only I could figure out what might have changed on branch to cause the XHR issues this guy in is seeing....  This certainly wasn't it. ;)

I'm just really glad we have unit tests on 1.9.0 and trunk.
Comment 16 Al Billings [:abillings] 2008-12-01 12:15:33 PST
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?
Comment 17 Martin Stránský 2008-12-08 06:33:15 PST
Created attachment 351892 [details] [diff] [review]
1.8.0 branch patch
Comment 18 Martin Stránský 2008-12-08 06:37:36 PST
Comment on attachment 351892 [details] [diff] [review]
1.8.0 branch patch

Can you please check the backport?
Comment 19 Alexander Sack 2008-12-16 00:57:20 PST
Comment on attachment 351892 [details] [diff] [review]
1.8.0 branch patch

a=asac for 1.8.0
Comment 20 Jonas Sicking (:sicking) 2009-01-27 15:54:46 PST
Marking as regression since this has been fixed on branch, but not yet on trunk
Comment 21 Damon Sicore (:damons) 2009-02-17 10:35:09 PST
Jonas, does this need another patch for trunk?  Or, do we just need to land?
Comment 22 Jonas Sicking (:sicking) 2009-02-24 19:26:44 PST
Fixed in bug 479521

Note You need to log in before you can comment on or make changes to this bug.