[OpenAjaxSecurity] Revisions to W3C Access Control

Kris Zyp kriszyp at xucia.com
Wed Jan 2 11:09:57 PST 2008


As far as I can tell from the HTTP spec, including the OPTIONS method seems
reasonable too, but that is not big deal.
Kr

On Jan 2, 2008 11:53 AM, Jon Ferraiolo <jferrai at us.ibm.com> wrote:

>  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 (
> http://www.json.com/2007/11/16/w3c-enabling-read-access-for-web-resources/)
> 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.
>
> Jon
>
> [image: Inactive hide details for Bertrand Le Roy
> <Bertrand.Le.Roy at microsoft.com>]Bertrand Le Roy <
> Bertrand.Le.Roy at microsoft.com>
>
>
>
>      *Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>*
>             Sent by: security-bounces at openajax.org
>
>             01/02/2008 10:14 AM   Please respond to
>             OpenAjax Alliance Security Task Force <
>             security at openajax.org>
>
>
> To
>
> OpenAjax Alliance Security Task Force <security at openajax.org>
> cc
>
>
> Subject
>
> Re: [OpenAjaxSecurity] Revisions to W3C Access Control
>
> That actually makes sense. Thanks for the clarification.
>
> *From:* security-bounces at openajax.org [
> mailto:security-bounces at openajax.org <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.
> Kris
> On Jan 2, 2008 10:56 AM, Bertrand Le Roy <*Bertrand.Le.Roy at microsoft.com*<Bertrand.Le.Roy at microsoft.com>>
> wrote:
>
> 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* <security-bounces at openajax.org>[mailto:
> * security-bounces at openajax.org* <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 * <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* <security-bounces at openajax.org> [*mailto:security-bounces at openajax.org
> * <security-bounces at openajax.org>]
> > On Behalf Of Jon Ferraiolo
> > Sent: Wednesday, January 02, 2008 7:57 AM
> > To: *security at openajax.org* <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*<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/*<http://lists.w3.org/Archives/Public/public-appformats/>
> > 2007Dec/0054.html>
> > [AC] <*http://www.w3.org/TR/access-control/*<http://www.w3.org/TR/access-control/>
> >
> > [AC-Editor] <* http://dev.w3.org/2006/waf/access-control/*<http://dev.w3.org/2006/waf/access-control/>
> >
> >
> >
> > Begin forwarded message:
> >
> > > Resent-From: *public-appformats at w3.org* <public-appformats at w3.org>
> > > From: "ext Close, Tyler J." <*tyler.close at hp.com* <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>" <*
> 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/* <http://www.w3.org/mid/>
> > > *C7B67062D31B9E459128006BAAD0DC3D10BA654A at G6W0269.americas.hpqcorp.net
> * <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/*<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/ *<http://www.w3.org/TR/access-control/>
> >
> > >
> > _______________________________________________
> > security mailing list
> > *security at openajax.org * <security at openajax.org>
> > *http://openajax.org/mailman/listinfo/security*<http://openajax.org/mailman/listinfo/security>
>
> _______________________________________________
> security mailing list*
> **security at openajax.org* <security at openajax.org>*
> **http://openajax.org/mailman/listinfo/security*<http://openajax.org/mailman/listinfo/security>
> _______________________________________________
> security mailing list
> security at openajax.org
> http://openajax.org/mailman/listinfo/security
>
>
> _______________________________________________
> security mailing list
> security at openajax.org
> http://openajax.org/mailman/listinfo/security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/security/attachments/20080102/dd182379/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080102/dd182379/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/security/attachments/20080102/dd182379/attachment-0003.gif 


More information about the security mailing list