Fwd: Comments on: Access Control for Cross-site Requests

Hi Doug,

Tyler Close quotes you in the e-mail below (archived at [WAF- 
Archive]) regarding the W3C's Access Control for Cross-site Requests  
spec (see [AC] for the last publication by the W3C and [AC-Editor]  
for the latest version of the Editor's Draft).

Tyler's e-mail resulted in an interesting exchange (follow [WAF- 
Archive]). I invite your comments on this thread as well as an  
elaboration on "more elegant and reliable approaches to providing a  
safe alternatives to the script tag hack".

Regards, Art Barstow

[WAF-Archive] <http://lists.w3.org/Archives/Public/public-appformats/ 
2007Dec/0054.html>
[AC] <http://www.w3.org/TR/access-control/>
[AC-Editor] <http://dev.w3.org/2006/waf/access-control/>


Begin forwarded message:

> Resent-From: public-appformats@w3.org
> From: "ext Close, Tyler J." <tyler.close@hp.com>
> Date: December 19, 2007 8:17:29 PM EST
> To: "public-appformats@w3.org" <public-appformats@w3.org>
> Subject: Comments on: Access Control for Cross-site Requests
> Archived-At: <http://www.w3.org/mid/ 
> C7B67062D31B9E459128006BAAD0DC3D10BA654A@G6W0269.americas.hpqcorp.net>
>
>
> Hi all,
>
> I'm on the W3C's Web Security Context WG, where we got a request  
> for review of your document "Access Control for Cross-site  
> Requests". I'm glad there's a group working on this problem, as  
> it's functionality that's sorely needed. I've got some comments of  
> my own on your current design and have also collected some feedback  
> from Doug Crockford, which I'm including in the email. We've both  
> independently come to similar opinions on this first draft.
>
> A significant portion of the proposal is devoted to specifying a  
> policy language for determining whether or not a page from a  
> particular "root URI" should be allowed to issue a cross-domain  
> request to a particular server. I think the problem can be solved  
> without the server and the client software agreeing on such a  
> policy language. For example, rather than have the server specify  
> the rules for cross-domain requests and have the client enforce  
> these rules, the client should simply send the request information  
> to the server and have the server enforce its own rules. I see no  
> advantage to placing this logic in the client, as opposed to the  
> server. Placing the logic in the client introduces significant  
> complexity which creates many opportunities for implementation  
> bugs, specification ambiguity and misunderstanding by web  
> application developers, while possibly limiting the kinds of  
> policies a server can enforce.
>
> There is also a significant factual error in the document's  
> Introduction:
>
> """
> However, it is not possible to exchange the contents of resources  
> or manipulate resources "cross-domain".
> """
>
> It *is* possible to manipulate resources "cross-domain". An HTML  
> page can contain a FORM which submits an HTTP request "cross- 
> domain". Submission of this request can be automated using  
> Javascript. The Same Origin Policy only prevents the HTML page from  
> accessing the response to the issued request. Manipulation is  
> allowed. Only responses are protected, not requests.
>
> Below are comments from Doug Crockford:
>
> --- Begin Doug's comments ---
> re: http://www.w3.org/TR/access-control/
>
> Currently, the script tag hack is the best available method for  
> accessing data
> from a server other than the origin server. It works (in fact, it is
> programmatically much more convenient than the XMLHttpRequest) but  
> it has
> horribly unacceptable security properties. There is an urgent need  
> to a better
> alternative.
>
> The Access Control proposal is a big improvement over the current  
> state of the
> art, but I wish that it could be better still. It is a patch on a  
> patch, and
> while it appears that the patch will hold this time, I wish we  
> could agree on a
> cleaner approach.
>
> Ideally, the server should be responsible for determining how it  
> dispenses its
> data. Unfortunately, the Same Origin Policy has in many cases  
> induced the
> abdication of the server's responsibility. The current proposal  
> extends this bad
> practice. The server sends a policy statement with the data to the  
> browser. The
> browser must interpret the policy statement and decide whether or  
> not to deliver
> the data to the application. I think this is perverse. The server  
> should not be
> putting bits on the wire that it does not want delivered. The proposal
> encourages bad practice.
>
> The proposal also invents another language. It presents another  
> opportunity for
> system administrators to get something wrong.
>
> I believe there are more elegant and reliable approaches to  
> providing a safe
> alternatives to the script tag hack.
> --- End Doug's comments ---
>
> --Tyler
>
> --
> [1] "Access Control for Cross-site Requests"
>     <http://www.w3.org/TR/access-control/>
>

Received on Wednesday, 2 January 2008 13:23:14 UTC