Closed
Bug 290100
Opened 19 years ago
Closed 19 years ago
XMLHttpRequest affected by document.domain setting
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
RESOLVED
FIXED
People
(Reporter: brendan, Assigned: peterv)
References
()
Details
(Keywords: fixed1.8)
Attachments
(1 file)
1.65 KB,
patch
|
caillon
:
review+
peterv
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
IE does not change the origin to which XMLHttpRequest's open method is restricted when document.domain is set to a super-domain of that origin. We do. Seems like a bug, although perhaps (at least for our own backward compatibility) we should allow a URI under either the original or the current domain to be opened. /be
Reporter | ||
Comment 1•19 years ago
|
||
Let's try better assignment ;-). /be
Assignee: xml → jst
QA Contact: ashshbhatt → ian
Reporter | ||
Comment 2•19 years ago
|
||
https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=XMLHttpRequest&field0-0-1=component&type0-0-1=substring&value0-0-1=XMLHttpRequest&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=XMLHttpRequest&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=XMLHttpRequest&field1-0-0=product&type1-0-0=substring&value1-0-0=domain&field1-0-1=component&type1-0-1=substring&value1-0-1=domain&field1-0-2=short_desc&type1-0-2=substring&value1-0-2=domain&field1-0-3=status_whiteboard&type1-0-3=substring&value1-0-3=domain shows dupage. Could someone other than me (who has too little time right now) pls. check those out and dup them forward against this bug? /be
Comment 3•19 years ago
|
||
In other words, most people expect XMLHttpRequest to work in the same way as any other origin-related security feature - as described in the following document: http://www.mozilla.org/projects/security/components/same-origin.html Experience tells me that the current situation with bug raises serious problems for anyone attempting to write so called "AJAX" style applications spanning over multiple servers. (Without resorting to some sort of URL-based load balancing, that is...) Speaking of dupes, I have seen bug #280188 being updated as "blocking" over the last few days...
Comment 4•19 years ago
|
||
> In other words, most people expect XMLHttpRequest to work in the same way as > any other origin-related security feature - as described in the following > http://www.mozilla.org/projects/security/components/same-origin.html It does, that's the problem. If document.domain is set "the shorter domain is used for subsequent origin checks" -- meaning you can only access pages on that shorter domain. The reason this works for frames is that both frames set document.domain. That only works because we don't block the load, we load the frame and run its scripts first before checking for access between them. bug 163950 claims to have fixed this specific case (accessing the original host), but the patch looks like it was fixing something else. Nominating for 1.8b4 because dupe 280188 was marked blocking. honoring document.domain is actually problematic. Without anything checking that the host we're loading from really is who it says it is this could be used to fish around inside a firewall for XML data (see advisory in attachment 89639 [details] and bug 154930).
Flags: blocking1.8b4?
Comment 5•19 years ago
|
||
*** Bug 280188 has been marked as a duplicate of this bug. ***
Comment 6•19 years ago
|
||
*** Bug 229711 has been marked as a duplicate of this bug. ***
Comment 7•19 years ago
|
||
Agreed, the Same Origin Policy security concerns are not to be ignored. But
isn't this a case of having to weight the possibility of successfully exploiting
such a situation against the added creative possibilities?
Maybe there's a middle road, like having ONE setting in about:config to allow
developers to at least play around. Or just a consistent behaviour.
By the way, the advisory is a bit unclear on one point:
> 1) Attacker controls DNS zone *.baz.com, configuring it as follows:
It should be pointed out that "*.baz.com" means that is can be *any* domain
controlled that the attacker controls, not necessarily BigCo's. If it's
BigCo.com, they have far bigger concerns.
Comment 8•19 years ago
|
||
(In reply to comment #7) > By the way, the advisory is a bit unclear on one point: > > 1) Attacker controls DNS zone *.baz.com, configuring it as follows: > > It should be pointed out that "*.baz.com" means that is can be *any* domain > controlled that the attacker controls, not necessarily BigCo's. The attacker doesn't control BigCo's domain, *.baz.com is entirely separate. bar.baz.com doesn't physically exist, but the evil baz.com DNS reports an address for it that the victim's client will interpret as local. foo.bar.baz.com exists, and sets domain to bar.baz.com Carrying over blocking flag from bug 280188
Flags: blocking1.8b4? → blocking1.8b4+
Comment 9•19 years ago
|
||
Johnny, or brendan, any ideas who can help out here? JST's b4 list is pretty full and this looks important.
Reporter | ||
Comment 10•19 years ago
|
||
Jonas, I thought I cc'd you on this -- maybe there's a dup out there. Cc'ing peterv too in case he can help. /be
Assignee | ||
Comment 11•19 years ago
|
||
(In reply to comment #4) > bug 163950 claims to have fixed this specific case (accessing the original > host), but the patch looks like it was fixing something else. Actually, https://bugzilla.mozilla.org/show_bug.cgi?id=163950#c9 seems to imply it fixed it the other way round: "This patch will allow, for example, a script on a page at a.b.com that has set document.domain to b.com to open an XMLRequest to http://b.com/file.xml. It will *not* allow the same page to open a request to http://a.b.com/file.xml." I think I've got a fix, but it'll also apply to SOAP and XMLDocument.load, I guess that's what we want? Also, given comment 4 I gather we don't want to allow loads from both domains after all?
Assignee: jst → peterv
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•19 years ago
|
||
This makes us use the real origin, ignoring document.domain on the subject.
Attachment #193570 -
Flags: review?(dveditz)
Updated•19 years ago
|
Attachment #193570 -
Flags: review?(dveditz) → review?(brendan)
Updated•19 years ago
|
Severity: normal → major
Reporter | ||
Comment 13•19 years ago
|
||
Comment on attachment 193570 [details] [diff] [review] v1 r=me, a=drivers for 1.8b4. /be
Attachment #193570 -
Flags: review?(brendan)
Attachment #193570 -
Flags: review+
Attachment #193570 -
Flags: approval1.8b4+
Assignee | ||
Comment 14•19 years ago
|
||
Comment on attachment 193570 [details] [diff] [review] v1 Morphing brendan's r+ into sr+.
Attachment #193570 -
Flags: superreview+
Attachment #193570 -
Flags: review?(caillon)
Attachment #193570 -
Flags: review+
Updated•19 years ago
|
Flags: blocking1.8b5+
Updated•19 years ago
|
Attachment #193570 -
Flags: review?(caillon) → review+
Reporter | ||
Comment 15•19 years ago
|
||
peterv, can you land on branch and trunk ASAP. /be
Assignee | ||
Comment 16•19 years ago
|
||
Checked in on trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Keywords: fixed1.8
Comment 17•19 years ago
|
||
The patch seems so solve xmlhttprequest.open( "GET", ...) but not xmlhttprequest.open( "POST", ...) ?
Assignee | ||
Comment 18•19 years ago
|
||
(In reply to comment #17) > The patch seems so solve xmlhttprequest.open( "GET", ...) but not > xmlhttprequest.open( "POST", ...) ? It should have fixed both.
Updated•19 years ago
|
Flags: testcase?
You need to log in
before you can comment on or make changes to this bug.
Description
•