458248 - (CVE-2008-5506) XMLHttpRequest 302 response disclosure

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[marius schilder]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

So we have server at example.org, running XHR to example.org, which redirects to example.com ?

Comment 2

[marius schilder]

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) No longer reading bugmail consistently]

XS-XHR might have "fixed" this.

Comment 4

[Daniel Veditz [:dveditz]]

> XS-XHR might have "fixed" this.

That doesn't help FF3. I bet this affects FF2 as well.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Branch fix

Got r/sr from mrbkap

Comment 6

[Daniel Veditz [:dveditz]]

Comment on attachment 348717 [details] [diff] [review]
Branch fix

approved for 1.8.1.19 and 1.9.0.5, a=dveditz for release-drivers

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Checked in

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, I think this might not be fixed on trunk, even with XS-XHR support :(

Comment 9

[Boris Zbarsky [:bzbarsky]]

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?

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Aww crap, it is not :(

Comment 11

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: Branch fix fix

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 350230 [details] [diff] [review]
Branch fix fix

Duh :)

Comment 13

[Samuel Sidler (old account; do not CC)]

Comment on attachment 350230 [details] [diff] [review]
Branch fix fix

Approved for 1.8.1.19. a=ss

Please land on the 1.8 branch as soon as possible.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Landed on 1.8 branch.

Thanks for noticing bz!

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[Al Billings [:abillings - ex-MoCo]]

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ý [:stransky] (ni? me)]

Attachment: 1.8.0 branch patch

Comment 18

[Martin Stránský [:stransky] (ni? me)]

Comment on attachment 351892 [details] [diff] [review]
1.8.0 branch patch

Can you please check the backport?

Comment 19

[Alexander Sack]

Comment on attachment 351892 [details] [diff] [review]
1.8.0 branch patch

a=asac for 1.8.0

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Marking as regression since this has been fixed on branch, but not yet on trunk

Comment 21

[Damon Sicore (:damons)]

Jonas, does this need another patch for trunk?  Or, do we just need to land?

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Fixed in bug 479521