[OpenAjaxSecurity] Revisions to W3C Access Control

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Wed Jan 2 14:39:00 PST 2008


Yes, so I realized after sending the e-mail. I read the specs in its entirety and as far as I'm concerned the only issue I see remaining is about using HEAD instead of GET when the purpose of the request is just to get the access control data.

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

As mentioned before, a key aspect of this, is that the browser will not allow access to the XHR response unless the server opted-in and added the Access-Control header. So this does not open up any existing servers to attack, since no existing server currently adds a Access-Control header. The big question though is whether it is too tempting for existing servers to add this header without considering the access they are opening up. The fact that they have chosen to opt-in should mean that they are aware that other sites can access their info, and they are prepared for that. On the otherhand stripping cookies does seem like it would force even more caution by servers. Either way is fine with me.
And no, GET is not a two-step dance. The response is returned to the browser, and the browser decides whether to allow the JS access to the response based on the Access-Control response header.
Kris
On Jan 2, 2008 3:24 PM, Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>> wrote:

I'm not sure I'm getting how sending cookies doesn't open new attacks.

Here's the scenario, which may not be the most well thought out security setting but browsers today protect that against unwanted access:

-          Web site has a confidential page that is protected by a persistent authorization cookie (granted this is not the most secure setting but it works today)

-          That page is currently not accessible to CSRF because opening the page in a frame will prevent DOM reading because of existing same domain policies, and opening it with a script tag will not help either as the contents is just not script and has no chance of sending info anywhere. XHR is of course out of the question because of different domains.

-          Tomorrow, evilsite.com<http://evilsite.com/> can trick the user of this page into browsing a page that does a background XHR that will have all the right cookies and read the results and send them where it wants.



I don't think this is just opening wider a door that was already open but I may be mistaken.



I will ping the IE team to check that they are aware of the spec (I would be amazed if they weren't) and check that they sent or will send any feedback they have.



From: security-bounces at openajax.org<mailto:security-bounces at openajax.org> [mailto: security-bounces at openajax.org<mailto:security-bounces at openajax.org>] On Behalf Of Jon Ferraiolo
Sent: Wednesday, January 02, 2008 2:06 PM

To: OpenAjax Alliance Security Task Force
Subject: Re: [OpenAjaxSecurity] Revisions to W3C Access Control



There have been 5 emails recently on the subject of Access Control and cookies. Here are Michael Steiner's comments:

* http://openajax.org/pipermail/security/2007q4/000194.html

You can read his exact words, but Michael is saying that Access Control does open the CSRF door a little wider, but that door is already open and people need to shut the door regardless. Therefore, there isn't a compelling strong argument to present to the W3C folks who believe the cross-site data access benefit is of high value (versus maybe making an existing problem worse).

So, if you think we should complain about Access Control sending cookies, please propose the exact words.

Back to the question about whether the WAF WG will give more clout to OpenAjax Alliance rather than Microsoft, after further thinking, I would say Microsoft because of the importance of IE. Which leads me to propose that you make sure the IE team is aware of Access Control and (hopefully) will send feedback to the W3C sooner rather than later. In particular, on the extreme side, if the IE team believes that there are major security problems with Access Control and therefore would never implement the feature, the W3C should hear that.

Jon


[cid:image001.gif at 01C84D4D.36C52750]Bertrand Le Roy < Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>
Sent by: security-bounces at openajax.org<mailto:security-bounces at openajax.org>

01/02/2008 01:47 PM

Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org>>





To



OpenAjax Alliance Security Task Force <security at openajax.org <mailto:security at openajax.org> >




cc







Subject



Re: [OpenAjaxSecurity] Revisions to W3C Access Control











The fact that cookies are being sent on cross-domain requests? Do we think there's a problem with that?

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

OK, I can send an email, but only if people contribute some feedback for me to forward. The latest dialog has been about GET, HEAD and OPTIONS, where we think the 2-step dance should work with all three, not just GET. What other feedback or questions do we want to submit?

[cid:image001.gif at 01C84D4D.36C52750]Bertrand Le Roy < Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>
Sent by: security-bounces at openajax.org<mailto:security-bounces at openajax.org>

01/02/2008 11:51 AM

Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org>>



To


OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org>>


cc





Subject


Re: [OpenAjaxSecurity] Revisions to W3C Access Control











I'd prefer if the message originated from OpenAjax if people agree with this. An industry group (including MS) should have more weight than just MS, right?

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

I am OK with any approach. The key thing is to send our feedback, whether it is in one message or multiple messages, and whether it is coordinated across the Security TF or just one person expressing their opinions.

Here is a concrete suggestion. How about if you send an email message on behalf of Microsoft to the WAF WG, but before sending that message, you run it past the SecurityTF for feedback?

Jn

[cid:image001.gif at 01C84D4D.36C52750]Bertrand Le Roy < Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>
Sent by: security-bounces at openajax.org<mailto:security-bounces at openajax.org>

01/02/2008 10:58 AM



Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org> >



To


OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org>>


cc





Subject


Re: [OpenAjaxSecurity] Revisions to W3C Access Control











Should we maybe compile a list of our objections and send that in one message?

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

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

[cid:image001.gif at 01C84D4D.36C52750]Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto:Bertrand.Le.Roy at microsoft.com>>
Sent by: security-bounces at openajax.org<mailto:security-bounces at openajax.org>

01/02/2008 10:14 AM



Please respond to
OpenAjax Alliance Security Task Force <security at openajax.org<mailto:security at openajax.org>>



To


OpenAjax Alliance Security Task Force <security at openajax.org<mailto: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> [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.
Kris
On Jan 2, 2008 10:56 AM, Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com<mailto: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<mailto:security-bounces at openajax.org> [mailto: 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 <mailto: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> [ mailto:security-bounces at openajax.org ]
> On Behalf Of Jon Ferraiolo
> Sent: Wednesday, January 02, 2008 7:57 AM
> To: security at openajax.org<mailto: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<mailto:public-appformats at w3.org>
> > From: "ext Close, Tyler J." < tyler.close at hp.com<mailto:tyler.close at hp.com>>
> > Date: December 19, 2007 8:17:29 PM EST
> > To: " public-appformats at w3.org<mailto:public-appformats at w3.org>" <public-appformats at w3.org<mailto: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<mailto: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 <mailto:security at openajax.org>
> http://openajax.org/mailman/listinfo/security

_______________________________________________
security mailing list
security at openajax.org<mailto:security at openajax.org>
http://openajax.org/mailman/listinfo/security
_______________________________________________
security mailing list
security at openajax.org<mailto:security at openajax.org>
http://openajax.org/mailman/listinfo/security _______________________________________________
security mailing list
security at openajax.org<mailto:security at openajax.org>
http://openajax.org/mailman/listinfo/security_______________________________________________
security mailing list
security at openajax.org<mailto:security at openajax.org>
http://openajax.org/mailman/listinfo/security_______________________________________________
security mailing list
security at openajax.org<mailto:security at openajax.org>
http://openajax.org/mailman/listinfo/security

_______________________________________________
security mailing list
security at openajax.org<mailto: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/f8828da8/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
Url : http://openajax.org/pipermail/security/attachments/20080102/f8828da8/attachment-0001.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 168 bytes
Desc: image002.png
Url : http://openajax.org/pipermail/security/attachments/20080102/f8828da8/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 166 bytes
Desc: image003.png
Url : http://openajax.org/pipermail/security/attachments/20080102/f8828da8/attachment-0003.png 


More information about the security mailing list