Re: IE Team's Proposal for Cross Site Requests

Eric Lawrence schreef:
> Note that XDR supports only the GET and POST methods, DELETE and other methods are not supported.
>   

I don’t really see how POST is less harmful than DELETE. POST (if used 
in a REST-y way) can be used to wreak serious havoc (e.g. spam messages, 
overload server data capacity, post viruses, adding new super user 
accounts for the hacker, change settings such as passwords, influence 
poll results).

Additionally, there are a great number of sites that are using the HTTP 
POST method for operations that would be more suitable for PUT and 
DELETE. The reason that this happens is probably HTML’s fault, because 
it only supports GET and POST, crippling the functionality that HTTP 
provides. Non-REST webservices protocols such as XML-RPC and SOAP also 
exclusively use POST.

If XDR only supports GET and POST, it encourages sites to use POST to 
implement delete functionality and abuse the HTTP protocol because that 
is the only way they can get the functionality they desire to work. 
Basically, you’re boycotting REST in favour of SOAP.

So, I do not see much benefit in the decision to disallow DELETE but 
allowing POST.

> XDR is intended for "public" data.  We explicitly suggest that Intranet servers do not expose private data through this mechanism.  In order to ensure that no existing servers/services (in any zone) are put at risk, XDR does not send credentials of any sort, and requires that the server acknowledge the cross-domain nature of the request via the response header.
>   

I don’t think you’re really keeping users very safe that way. To quote 
an example, PHP is by default configured to send session credentials 
entirely through sessionID link parameters when cookies are not 
available, and thus don’t need cookies or authentication headers. And on 
many sites (e.g. phpBB-based forums), communication with the server 
(including deletion) happens exclusively through GET and POST requests. 
XDR’s restrictions on methods and credentials will not do these sites 
any good. Rather, they encourage even more sites to work around the 
restrictions.

Additionally, if you really want to keep sites safe in this manner, you 
should disallow cross-site POST requests for both XDR and HTML forms. 
Otherwise, there is already a breach in the safety, POST is equally 
suitable for ‘public’ data as DELETE and PUT are. You should allow those 
methods, so that developers can at least provide a proper REST API and 
are not forced to overload POST like XML-RPC and SOAP and friends do.

> Laurens Holst [lholst@students.cs.uu.nl] asked:
> <<So, if I cannot set HTTP headers, how am I supposed to set an Accept
> header to indicate that I e.g. want to receive application/xhtml+xml,
> application/atom+xml, application/*rss*+xml, application/rdf+xml, etc.?
> Your proposal is completely unfriendly to content negotiation. Also,
> there are valid use cases for setting other headers.
>
> I sincerely hope you will fix this issue by creating a blacklist of
> headers instead of disallowing them entirely.>>
>
> We absolutely agree that it is possible to define use cases that XDR does not accommodate.  We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser.
>
> Creating a "blocklist" of headers is problematic as there is no existing mechanism to determine whether a target server will interpret a given header in a particular way.
>
> By way of example, we are aware of servers which utilize custom HTTP request headers as an anti-CRSF mechanism.  Such servers assume that, because the only mechanism currently available in the browser to send custom headers is via XMLHTTPRequest, if such custom headers are present, then the request "must" be from a same-origin XHR object.  Hence, permitting use of custom headers in XDR would expose such servers to attack.  It's absolutely reasonable to argue that such servers never should have made such assumptions, however we do not feel it is appropriate to put servers at risk.
>   

Then create a whitelist, with at least the Accept-* headers on it. They 
are clearly defined, and it is doubtful that they are used in a 
different manner than described. The use cases are clear and plenty.

> While HTTP-based content-negotiation is certainly well-defined by the HTTP specifications, for operational reasons it is relatively uncommon in the wild.  Different content types are usually served from different URLs; for instance, you can see that Yahoo!-based services use a URL parameter to pivot between JSON and XML format (http://developer.yahoo.com/common/json.html).
>   

I don’t think it is up to Microsoft to decide that content negotiation 
is useless and that part of HTTP should not be supported even though it 
poses no security risk. Part of the reason that content type negotiation 
is reasonably uncommon in the wild is partially because of mediocre 
support by user agents. By the way, content language and content 
encoding negotiation is pretty common, actually.

Content type negotiation is very useful and I think a very nice feature 
of HTTP, offering different ‘views’ (e.g. RSS or RDF, SVG or PNG) of the 
same content. With XHR it was finally possible to use content type 
negotiation in a good way in browsers, please don’t break it again in XDR.

I also think your argument here is inconsistent with the functionality 
XDR provides, since you DO support specifying the content type for POST 
entity bodies (contentType property).

If you decide to not allow manipulation of the Accept header anyway, you 
should make sure to NOT send an Accept header in the request at all, 
because it would not be able to reflect the content that the requestee 
intended to receive.

> 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.
>   

This is also the case for XDR, no? The user can specify an arbitrary 
POST body, with arbitrary content type.

I think that is all I have to say :).


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.