[OpenAjaxSecurity] Revisions to W3C Access Control

Jon Ferraiolo jferrai at us.ibm.com
Wed Jan 2 07:57:27 PST 2008



Happy New Year!

There has been recent discussion at the W3C about the Access Control
specification, with the result that the editorial draft now contains a
revised approach to POST (and DELETE). They haven't included a change log
and I don't know how to do a 'diff', but it appears that the changes are
captured within the "Introduction" section of the latest editorial draft:

* http://dev.w3.org/2006/waf/access-control/#introduction

With these changes, if you want to do a cross-site POST, the new 2-step
dance goes as follows:

1) Do a GET to the URI. If the server opts into Access Control and allows
cross-site POST, then it will return the following 2 HTTP headers (along
with any data that comes with the GET):

Access-Control: allow <hello-world.invalid> method DELETE, POST
Method-Check-Expires: Sun, 06 Nov 2012 08:49:37 GMT

2) Do a POST to the URI. A browser that supports Access Control will allow
the cross-site POST if that site has previously allowed POST access and if
the expiration time has not happened yet.

What do people think of this new approach? To me, it doesn't add any
security negatives to the previous approach and maybe helps some by
including a timeout mechanism. However, from a security perspective,
fundamentally the same analysis applies as with the previous version of
Access Control: the server still needs to set up CSRF protection.

Jon

-----------------------
(email from W3C WAF WG to Doug Crockford)

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 at w3.org
> From: "ext Close, Tyler J." <tyler.close at hp.com>
> Date: December 19, 2007 8:17:29 PM EST
> To: "public-appformats at w3.org" <public-appformats at w3.org>
> Subject: Comments on: Access Control for Cross-site Requests
> Archived-At: <http://www.w3.org/mid/
> C7B67062D31B9E459128006BAAD0DC3D10BA654A at 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/>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080102/41e9b6de/attachment.html 


More information about the security mailing list