Bug 458248 (CVE-2008-5506)

XMLHttpRequest 302 response disclosure

RESOLVED FIXED in mozilla1.9.1

Status

()

Core
DOM
P2
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: marius schilder, Assigned: sicking)

Tracking

(4 keywords)

unspecified
mozilla1.9.1
fixed1.8.1.19, fixed1.9.1, regression, verified1.9.0.5
Points:
---
Bug Flags:
blocking1.9.1 +
blocking1.9.0.5 +
wanted1.9.0.x +
blocking1.8.1.19 +
wanted1.8.1.x +
blocking1.8.0.next +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate])

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
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
Component: Security → DOM
Product: Firefox → Core
QA Contact: firefox → general
Version: unspecified → 1.9.0 Branch
So we have server at example.org, running XHR to example.org, which redirects to example.com ?
(Reporter)

Comment 2

9 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x?
Flags: blocking1.9.0.4?
Flags: blocking1.8.1.18?
Whiteboard: [sg:moderate]
Assignee: nobody → jonas
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x+
Flags: blocking1.9.0.4?
Flags: blocking1.9.0.4+
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Version: 1.9.0 Branch → unspecified
Flags: blocking1.9.0.5+
Flags: blocking1.9.0.4+
Flags: blocking1.8.1.19+
Flags: blocking1.8.1.18+
Whiteboard: [sg:moderate] → [sg:moderate][needs branch patches]
Created attachment 348717 [details] [diff] [review]
Branch fix

Got r/sr from mrbkap
Attachment #348717 - Flags: superreview+
Attachment #348717 - Flags: review+
Attachment #348717 - Attachment description: Patch to fix → Branch fix
Attachment #348717 - Flags: approval1.9.0.5?
Attachment #348717 - Flags: approval1.8.1.19?
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
Attachment #348717 - Flags: approval1.9.0.5?
Attachment #348717 - Flags: approval1.9.0.5+
Attachment #348717 - Flags: approval1.8.1.19?
Attachment #348717 - Flags: approval1.8.1.19+
Whiteboard: [sg:moderate][needs branch patches] → [sg:moderate]
Checked in
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Keywords: fixed1.8.1.19, fixed1.9.0.5
Resolution: --- → FIXED
Actually, I think this might not be fixed on trunk, even with XS-XHR support :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: blocking1.9.1+
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 :(
Keywords: fixed1.8.1.19
Created attachment 350230 [details] [diff] [review]
Branch fix fix
Attachment #350230 - Flags: superreview?
Attachment #350230 - Flags: review?
Attachment #350230 - Flags: approval1.8.1.19?
Comment on attachment 350230 [details] [diff] [review]
Branch fix fix

Duh :)
Attachment #350230 - Flags: superreview?
Attachment #350230 - Flags: superreview+
Attachment #350230 - Flags: review?
Attachment #350230 - Flags: review+
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.
Attachment #350230 - Flags: approval1.8.1.19? → approval1.8.1.19+
Landed on 1.8 branch.

Thanks for noticing bz!
Keywords: fixed1.8.1.19
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?
Keywords: fixed1.9.0.5 → verified1.9.0.5

Updated

9 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1

Comment 17

9 years ago
Created attachment 351892 [details] [diff] [review]
1.8.0 branch patch

Updated

9 years ago
Attachment #351892 - Flags: review?(jonas)

Comment 18

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

Can you please check the backport?
Attachment #351892 - Flags: review?(jonas) → review+

Comment 19

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

a=asac for 1.8.0
Attachment #351892 - Flags: approval1.8.0.next+

Updated

9 years ago
Flags: blocking1.8.0.next+
Alias: CVE-2008-5506
Group: core-security
Marking as regression since this has been fixed on branch, but not yet on trunk
Keywords: regression
Jonas, does this need another patch for trunk?  Or, do we just need to land?
Depends on: 479521

Updated

9 years ago
Whiteboard: [sg:moderate] → [sg:moderate] needs landing
Fixed in bug 479521
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [sg:moderate] needs landing → [sg:moderate]
You need to log in before you can comment on or make changes to this bug.