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

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

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).

*** 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

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?

This makes us use the real origin, ignoring document.domain on the subject.

Comment on attachment 193570 [details] [diff] [review] v1 r=me, a=drivers for 1.8b4. /be

Comment on attachment 193570 [details] [diff] [review] v1 Morphing brendan's r+ into sr+.

peterv, can you land on branch and trunk ASAP. /be

Checked in on trunk and branch.

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.