[OpenAjaxSecurity] Revisions to W3C Access Control
jferrai at us.ibm.com
Wed Jan 2 09:51:30 PST 2008
Good question. I'm not sure, but I remember discussion on the WAF public
list where someone asked why they didn't use OPTIONS instead of GET and the
answer was that not many server technologies support HEAD. Therefore, my
guess is that there is a similar answer applies to HEAD (i.e., not used
much in practice). But this is partly speculation. I don't know for sure.
security-bounces at openajax.org wrote on 01/02/2008 09:28:18 AM:
> Do you know why the first step is a GET and not a HEAD?
> From: security-bounces at openajax.org
[mailto:security-bounces at openajax.org]
> On Behalf Of Jon Ferraiolo
> Sent: Wednesday, January 02, 2008 7:57 AM
> To: security at openajax.org
> Subject: [OpenAjaxSecurity] Revisions to W3C Access Control
> 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.
> (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/
> [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
> > 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
> > --
> >  "Access Control for Cross-site Requests"
> > <http://www.w3.org/TR/access-control/>
> security mailing list
> security at openajax.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the security