Re: IE Team's Proposal for Cross Site Requests

> How does this compare to the Cross-Site Extensions for XMLHttpRequest
> standard
> that is being developed by Web API and Web App Formats (and
> as implemented in Firefox betas)?
The major ones, IMO:
1. XDomainRequest uses a different constructor/API to make requests
(XDomainRequest instead of XMLHttpRequest).
2. XDomainRequest does not allow any headers. The W3C/AC for XSite requests
allows headers like "Accept" and "Accept-Language" which are crucial for the
fundamental HTTP capability of content and language negotiation.
3. Completely different server side response required to validate cross-site
requests are acceptable. XDomainRequest looks for a response header of
"XDomainRequestAllowed: 1", while W3C/AC, looks for an Access-Control header
which has more fine-grained control.
4. Cookies and credentials are not sent with XDomainRequest. I believe this
is still being discussed with W3C/AC.
5. Standard HTTP REST methods (PUT and DELETE) are not supported with
XDomainRequest, but are supported with W3C/AC.


> From Apple's point of view we would like to have a
> unified standard in this area.
>From web developer/framework developer's point of view, we would also
like a unified standard. Creating a new divergent API for cross-site
requests with XDR is certainly not the most beneficial approach for web
developers. Cross-site requests that work in all browsers (those that
implement W3C/AC and XDR) would look like:
if (window.XDomainRequest) {
    var xhr = new XDomainRequest(); // IE's cross-domain request technique
}
else {
    var xhr = new XMLHttpRequest(); // W3C and standards compliant browsers
cross-domain request technique
}
xhr.open("POST","http://otherdomain.com",true);
xhr.send();

And on the server, the server needs to at least set headers
"XDomainRequestAllowed: 1" and "Access-Control: allow *" for the responses
to be accessible in all browsers.
Does this seem like a clean API for devs? I think it would be much cleaner
and easier for developers if Microsoft adopted the W3C cross-site request
mechanism and worked to improve it, rather than creating a different API.

snipping from Chris's email:
> The short version is, as Sunava discusses in the summary of this mail,
> that x-domain XHR (and Flash’s approach, et al) is subject to specific
> x-domain injection attacks because of its persistent-allow design.

I understand that MS has security concerns, but rewriting the API is not
necessary to address these concerns. If there are aspects of the W3C/AC
proposal that MS doesn't like, I am sure discussion and feedback would be
welcome. Even minor deviations from W3C/AC proposal to satisfy the Microsoft
security concerns (such as stripping cookies, and requiring the
Access-Control header on every response) would be vastly better than using a
completely different API. I think the web development community would
appreciate standards convergence much more than multiple APIs. Having
multiple APIs increases complexity which increases the vector of possible
attacks.

> Specifically, any request sent by XDR could also be emitted by a
> properly coded HTML FORM object.  Hence, any “non-participating”
> web server put at risk by XDR is also at risk from simple HTML.

This is not true. I could send a POST request with XDR with a body of any
string. This is not possible in a form. A form strictly encodes everything
in URL encoded format. A server that expects that a body with pure JSON
would only come from a safe client (since this is not possible with a form),
would be in for a surprise with XDR. W3C/AC protects against this
vulnerability. IMO, this is a vulnerability and XDR may actually be
less secure than W3C/AC (and certainly less funtional).

Thanks,
Kris

Received on Saturday, 15 March 2008 15:06:36 UTC