280188 - Incorrect XmlHttpRequest document.domain security policy

Status: RESOLVED DUPLICATE of bug 290100

(Core :: XML, defect)

Description

[Kristian Kræmmer Nielsen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 (ax)

XmlHttpRequest fails if document.domain is set.
The provided link demostrates exactly what the difference is by normal
document.domain handling and what XmlHttpRequest forces.

Reproducible: Always

Steps to Reproduce:
If document.domain is changed and set to a shorter domain name than requested,
e.g. on a website with the domain '1.dev.jkkn.net':
document.domain='jkkn.net'
Actual Results:  
XmlHttpRequest will now only allow requests directly to the 'jkkn.net' domain
and no longer to '1.dev.jkkn.net'.

Expected Results:  
When using IFRAME's - it is still allowed to load pages from subdomain of the
the document.domain setting.

The demostration pages works perfectly in Internet Explorer.

There are two solutions to the problem as I see them:

1) You could allow XmlHttpRequest to request any subdomain of a configurated
document.domain setting. This would work fine and will act the same way as when
you do now set document.domain regarding requests performed back to the hostname
the webpages lives up on.
Some might arque that this is not secure enough, but actually provides the same
security as already exists by using IFRAMEs since here the document.domain is
set by the result from the server, which can be of any subdomain of the
document.domain setting.

2) Since the problem lies in that the respond to XmlHttpRequest is unable to set
document.domain in the same manner as by using IFRAME-requests. You could also
add security by allow Document Domain to be set in the respond of the request
header. So you like #1 you allow requests to any subdomain of the
document.domain setting, but the request must return an Document-Domain
HTTP-header with the exact same value as the script had set before the request.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Isn't the issue that XMLHttpRequest is only allowed to get data from the exact
server that the page is on (unlike iframes, which can load data from other sites)?

If so, this looks invalid, since the behavior is as-expected -- XMLHttpRequest
only getting data from the current page domain.

Comment 2

[Kristian Kræmmer Nielsen]

No, it does not do what you describe either - which is what in fact is strange.
The example page shows how requests to the exact same domain fails in Firefox.

It relays upon "document.domain" which makes no security that you can connect to
the same server or even IP.

If it uses "document.domain" it should have exact same policy applied that
IFRAME's otherwise it needs to use another attribute or security method to avoid
conflicts on pages that uses both technologies.

Comment 3

[Kristian Kræmmer Nielsen]

I think action needs to be taken soon to clarify this behaviour 
incompatibility with IE on this issue.

Either by going the way, as described by Boris, to make XmlHttpRequest be able 
to connect to the exact server that the page is upon (no matter of 
document.domain) or to use another consistent security model, like IE allowing 
any subdomain or document.domain or as used within Flash to connect back to 
the server (crossdomain.xml).

Comment 4

[Boris Zbarsky [:bzbarsky]]

Ian, what behavior are you specifying for this case?

Comment 5

[Asa Dotzler [:asa]]

Why is this bug still unconfirmed?

Comment 6

[Conny Brunnkvist]

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,
if I'm correct:

 http://www.mozilla.org/projects/security/components/same-origin.html

Comment 7

[Daniel Veditz [:dveditz]]

Duping to hopefully more active bug

*** This bug has been marked as a duplicate of 290100 ***

Comment 8

[José Jeria]

Shouldnt the blocking1.8b4+ be carried over to the other bug?