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: [email protected]
From: "ext Close, Tyler J." <[EMAIL PROTECTED]>
Date: December 19, 2007 8:17:29 PM EST
To: "[email protected]" <[email protected]>
Subject: Comments on: Access Control for Cross-site Requests
Archived-At: <http://www.w3.org/mid/
[EMAIL PROTECTED]>
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/>
