Closed Bug 290100 Opened 15 years ago Closed 15 years ago

XMLHttpRequest affected by document.domain setting

Categories

(Core :: XML, defect, major)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: brendan, Assigned: peterv)

References

()

Details

(Keywords: fixed1.8)

Attachments

(1 file)

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
Let's try better assignment ;-).

/be
Assignee: xml → jst
QA Contact: ashshbhatt → ian
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...
> 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?
*** Bug 280188 has been marked as a duplicate of this bug. ***
*** Bug 229711 has been marked as a duplicate of this bug. ***
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.
(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+
Johnny, or brendan, any ideas who can help out here? JST's b4 list is pretty
full and this looks important.
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
(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
Status: NEW → ASSIGNED
Attached patch v1Splinter Review
This makes us use the real origin, ignoring document.domain on the subject.
Attachment #193570 - Flags: review?(dveditz)
Attachment #193570 - Flags: review?(dveditz) → review?(brendan)
Severity: normal → major
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+
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+
Flags: blocking1.8b5+
Attachment #193570 - Flags: review?(caillon) → review+
peterv, can you land on branch and trunk ASAP.

/be
Checked in on trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
The patch seems so solve xmlhttprequest.open( "GET", ...) but not 
xmlhttprequest.open( "POST", ...) ?
(In reply to comment #17)
> The patch seems so solve xmlhttprequest.open( "GET", ...) but not 
> xmlhttprequest.open( "POST", ...) ?

It should have fixed both.
Flags: testcase?
Depends on: 450141
You need to log in before you can comment on or make changes to this bug.