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

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!

> 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. The server should
still check each request regardless of what it responded to the OPTIONS
request. For example, if the server disallows cross-site POST, not only
should it send a negative response to the OPTIONS request, but it should
also respond with an error if cross-domain POST requests come in the
future. (The rule is don't trust the client - the requests might not be
coming from a reliable browser such as Firefox but instead might be coming
from malicious software that is trying to look like a browser.)

Jon

>
> / Jonas
>