RE: IE Team's Proposal for Cross Site Requests

Maciej Stachowiak [mjs@apple.com] said:
<<But not exactly identical, since forms can't be used to POST XML content with a proper MIME type cross-domain.>>

You're right-- setting an arbitrary request content-type is a capability not present in HTML forms today.  While we believe that this is a minimal increase in attack surface, we agree that it's worth considering whether or not such capability should be removed.

If removed, all XDR POST requests could be sent with:

                Content-Type: text/plain; charset=UTF-8

Servers would then be flexible in interpreting the data in the higher-level format they expect (JSON, XML, etc).

Maciej Stachowiak [mjs@apple.com] asked:
<<What I'd like to understand is whether there are security benefits to the API and protocol differences.>>

We believe that the XDR proposal represents a simpler mechanism for enabling the most commonly requested types of cross-domain access.  We believe that such simplicity will lead to improved security in practical implementations by browsers.

There are many threats against a cross-domain communication mechanism, so we believe the simplicity of XDR makes it more suitable than attempting to plumb cross-domain capabilities into the existing XHR object.  In particular, we are concerned that attempting to introduce new restrictions/added complexity on an XHR object when it is used in a cross-domain manner will result in a confusing programming model for the web developer.


-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Saturday, March 15, 2008 1:23 PM
To: Eric Lawrence
Cc: Web API WG (public); public-appformats@w3.org; Sunava Dutta; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests


On Mar 14, 2008, at 4:59 PM, Eric Lawrence wrote:

>
> =====
>
> Maciej Stachowiak [mjs@apple.com] asked:
> <<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)? From Apple's
> point of view we would like to have a unified standard in this area.>>
>
> We believe that the XDR proposal exposes a smaller surface of attack
> than the Cross-Site extensions for XHR.  Specifically, it can be
> demonstrated that the capabilities exposed by XDR are virtually
> identical to the capabilities exposed by existing HTML tags.  The
> one exception (obviously) is that the XDR object allows examination
> of response bodies cross-domain if and only if the server explicitly
> indicates that such access is permissible via the
> XDomainRequestAllowed header.

But not exactly identical, since forms can't be used to POST XML
content with a proper MIME type cross-domain. This is actually more
restricted in XHR2+AC.

> =====
>
> Maciej Stachowiak [mjs@apple.com] asked, in part:
> <<I am also not sure if a DNS rebound cross-domain XHR with POST or
> some other method can do anything that you can't do with a cross-
> domain form submission. You can set custom headers, but that seems
> unlikely to make the difference between safe and unsafe.>>
>
> It's certainly a possibility.  For instance, consider a device which
> accepts SOAP XML as input  The designers of the device were wise to
> note that a cross-domain form submission could be made (encType =
> text/plain) that contains XML-formatted content, and thus they
> devised an anti-CSRF mechanism of rejecting requests that do not
> bear a proper SOAPAction header.  Such restriction properly blocks
> CSRF via HTML forms, but is put at risk if a cross-domain XHR
> request is able to send arbitrary headers.

On the other hand, if the anti-CSRF mechanism were checking for a
proper XML Content-Type instead of looking for a SOAPAction header,
XDR would be more vulnerable than XHR2+AC. If the server also checks
the Host header, then XHR2+AC would be completely safe (since no DNS
rebinding attack is then possible).

In any case, it seems like this could be addressed through a strict
whitelist of allowed request headers, including such critical headers
as Accept and Accept-Language but ruling out SOAPAction. Or XHR2+AC
could even block all custom headers on cross-site requests. Let's take
that point as negotiable. Allowed methods are also a negotiable point.
These issues both address what may be customized on the request, but
the most obvious incompatibilities between XDomainRequest and XHR2+AC
are the API and protocol.

What I'd like to understand is whether there are security benefits to
the API and protocol differences. Or if not, if there is any other
reason to prefer the Microsoft-proposed API and protocol to the
current draft standards. Can anyone from Microsoft address that point?

Regards,
Maciej

Received on Monday, 17 March 2008 21:30:41 UTC