Re: [AC] URI canonicalization problem with Access-Control-Policy-Path

Jon Ferraiolo wrote:
> public-appformats-request@w3.org wrote on 05/15/2008 04:19:40 PM:
> 
>  >
>  > > * Start with the current functionality of XDomainRequest
>  > > * Rename it to something suitably vendor-neutral (DataRequest)
>  > > * Keep the same basic handshaking approach from XDR where servers 
> reject
>  > > requests that don't have a DataRequest header and the browser rejects
>  > > responses that don't have a DataRequestAllowed header
>  > > * Add support for all of the same HTTP methods as in AC (i.e., not 
> just
>  > > GET and POST)
>  > > * Like AC and JSONRequest, the request includes the originating domain
>  > > that is making the cross-site request. (MS is likely to have heartburn
>  > > over this one because XDR doesn't send the domain for privacy reasons,
>  > > but maybe this can be a browser security preference  where some 
> browsers
>  > > can set a default of don't-send-originating-domain)
>  > > * Like XDomainRequest, there is a preflight check on all requests, but
>  > > the preflight check follows the approach used in AC, where
>  > > MyDataRequest.open(method, url) uses an OPTIONS request/response in 
> the
>  > > background for the pre-flight check
>  > > * The OPTIONS request returns not only a DataRequestAllowed:1 header
>  > > (per XDR) to indicate whether the given method is supported, but in 
> some
>  > > cases returns other headers that help with security, such as a Max-Age
>  > > header (per AC)
>  > > * Define another OPTIONS response header to allow a server to 
> opt-in to
>  > > transmission of cookies
>  > > * Decide whether the random delay feature from JSONRequest is a 
> good idea
>  > > * NOTE: the resulting technology does not include client-side 
> allow/deny
>  > > processing
>  > > * NOTE: the spec should SHOUT about vulnerability risks if certain
>  > > features are turned on (such as allowing POST/PUT/DELETE or 
> transmission
>  > > of cookies) and about how the server should not trust what is in the
>  > > request (such as the originating domain)
>  >
>  > It seems to me like with all these changes you rather end up with
>  > something much more similar to AC than XDR. With differently named
>  > headers (which of course matters very little).
> 
> If you feel that the deltas versus AC, such as dropping the client-side 
> allow/deny checking, are minor changes, fine with me!

Not really, but I feel like that is a much smaller delta between what 
you are proposing and the AC spec, than what you are proposing and the 
XDR spec.

Basically it looks like you are proposing the following changes to the 
AC spec:

* Changes to the names of various headers. E.g. "DataRequestAllowed" 
rather than "Access-Control". This certainly can be discussion, but 
overall seems pretty unimportant.
* Different syntax for the header to signal if access should be granted 
or not. I.e. changes to the syntax for the Access-Control header. I 
think this is basically the PEP discussion that has been raised a number 
of times.
* Ability to opt in to / out of receiving cookies. This has already been 
proposed in a thread started by Hixie ("Opting into cookies") so I 
suggest we take that discussion there.
* Investigate the random delay feature from JSONRequest. Please do start 
this as a separate thread.
* Some editorial changes to the spec to make it more explicit about 
various risks when opting into various features.

Am I missing something?

In general I would suggest starting separate threads for the changes to 
wish to do to the spec. This is how I would have like microsoft to have 
done their XDR proposal too. I think that would have resulted in much 
more productive and interesting discussions.

>  > Also, isn't doing the OPTIONS request moving the PEP into the client ;)
> 
> One key thing is that the allow/deny logic has moved to the server. The 
> OPTIONS request in effect is just an optimization thing.

What? The client MUST not send a DELETE or POST request unless it has 
checked with the server first, no? Or are you saying that the client MAY 
do the OPTIONS request if it wants to, or it is allowed to just go ahead 
and do send a DELETE request right away?

> The server 
> should still check each request regardless of what it responded to the 
> OPTIONS request.

But legacy servers will not do that right? So in order to protect those 
we need to rely on the client not sending harmful requests to them 
before checking using OPTIONS that that is ok?

/ Jonas

Received on Friday, 16 May 2008 03:00:37 UTC