Re: IE Team's Proposal for Cross Site Requests

On Mar 18, 2008, at 06:18, John Panzer wrote:

> Sunava Dutta wrote:
>> 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).
>>
> This assumes that the server can know a priori what type they  
> expect.  This isn't necessarily the case for e.g., AtomPub servers.   
> Or are they supposed to guess the content type from the content  
> body?  That's surely a recipe for security disasters down the road...


In general, the XDR design mindset seems to assume that the server- 
side implementation will jump through whatever hoops placed by the  
browser.

For contrast, let's consider how cross-site XHR didn't require  
excessive hoop jumping in the case of the Validator.nu Web service  
API[1].

I did not design this Web service API for a nightly of Firefox 3 or  
any browser. I designed the API for non-browser apps (e.g. blogging  
systems written in Python, Ruby or Java in a different process)  
applying what I thought to represent the best practices in RESTful Web  
service design. The idea of allowing cross-site XHR came as an  
afterthought.

It turned out that using GET for preflight sucked, and I sent feedback  
to the WG. However, after the spec changed to use OPTIONS, it was  
super-easy. The changes were confined to one request dispatching  
servlet class. The main controller class didn't need any changes. The  
filters that enable form-based uploads and compression didn't need any  
changes. Note that the same URI entry point is used for browser-based  
HTML and XHTML UI, form-based upload and the Web service API. Form  
POSTs and Web service POSTs are discriminated based on Content-Type.

Considering how non-disruptive the access-control-related changes were  
in a system that (I like to think) is a well-designed RESTful system,  
I think the access-control spec as it now stands (with OPTIONS) is  
pretty well designed. (Granted, Validator.nu is a bit abnormal in the  
sense that it doesn't have API keys, login or stuff like that, because  
the API is knowingly designed without a requirement to monetize the  
API.)

P.S. Using postMessage + same-site XHR as a surrogate for cross-site  
XHR would be bad in the Validator.nu case. Instead of adding a bit of  
OPTIONS handling in one place, I'd have to set aside a bit of URI  
space for serving an iframeable JS API from the same host name.  
(Currently, static content is served from a different host name by  
Apache without all the servlet stuff in between.) Moreover, I'd  
actually have to write the iframeable JS API. Even worse, that API  
would have to transport the document represented by a DOM tree across  
the postMessage boundary instead of merely passing the DOM tree to XHR  
for automatic serialization magic.

[1] http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 18 March 2008 09:44:18 UTC