On Mar 14, 2008, at 4:59 PM, Eric Lawrence wrote:
=====
Maciej Stachowiak [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
