[OpenAjaxSecurity] Revisions to W3C Access Control

Jon Ferraiolo jferrai at us.ibm.com
Wed Jan 2 10:53:19 PST 2008

Based on history, it may not be true that Kris's assumption about HEAD vs
GET reflects the authors of the Access Control spec's assumptions. About a
month ago, Kris assumed that W3C Access Control removed cookies
 but it turns out that the W3C intended that cookies would be sent. This
time, the string "HEAD" does not appear in the document. Therefore, someone
should ask the W3C whether both HEAD and GET are supported. I'll send such
an email unless someone else beats me to it.


             Bertrand Le Roy                                               
             microsoft.com>                                             To 
             Sent by:                  OpenAjax Alliance Security Task     
             security-bounces@         Force <security at openajax.org>       
             openajax.org                                               cc 
             01/02/2008 10:14          Re: [OpenAjaxSecurity] Revisions to 
             AM                        W3C Access Control                  
             Please respond to                                             
             OpenAjax Alliance                                             
               Security Task                                               
             <security at openaja                                             

That actually makes sense. Thanks for the clarification.

From: security-bounces at openajax.org [mailto:security-bounces at openajax.org]
On Behalf Of Kris Zyp
Sent: Wednesday, January 02, 2008 10:11 AM
To: OpenAjax Alliance Security Task Force
Subject: Re: [OpenAjaxSecurity] Revisions to W3C Access Control

I think this is actually more similiar in communication style to the
"Accept" and "Accept-Ranges" headers defined in the HTTP spec, in terms of
communicating capability offerings to the client, and following the
precedence of such would be advisable. These headers can be including in
any and all HTTP responses, regardless of the request method. The request
method seems like it should be orthogonal to the intent of a server sending
a list of authorized methods, I would think any method should work (except
obviously a method that hasn't been authorized yet). Both a GET and HEAD
have utility. In many situations, a POST will always be preceded by a GET
request, and utilizing that request to determine authorization makes sense,
in other situations a POST may not be preceded by a GET, and a HEAD would
be more efficient.
On Jan 2, 2008 10:56 AM, Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>

Uh? What server technology doesn't support HEAD?? They should at least make
it a possibility. It's a huge waste to send the full resource just to
authorize POST. What's the best way to send this feedback?

From: security-bounces at openajax.org [mailto: security-bounces at openajax.org]
On Behalf Of Jon Ferraiolo
Sent: Wednesday, January 02, 2008 9:52 AM
To: OpenAjax Alliance Security Task Force
Subject: Re: [OpenAjaxSecurity] Revisions to W3C Access Control

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.
> 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/ >
> >
> _______________________________________________
> security mailing list
> security at openajax.org
> http://openajax.org/mailman/listinfo/security

security mailing list
security at openajax.org
security mailing list
security at openajax.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080102/d58955ac/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080102/d58955ac/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic14373.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080102/d58955ac/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080102/d58955ac/attachment-0005.gif 

More information about the security mailing list