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 Saturday, 15 March 2008 20:23:27 UTC