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

Jonas Sicking <jonas@sicking.cc> wrote on 05/15/2008 07:50:14 PM:

> 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.

I really don't care whether the starting point is AC or XDR or whatever,
only that the proposal is acceptable to all and doesn't harm the security
of the Web.

>
> 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.

My key point was unifying the security features from various proposals, not
the names for the headers.

> * 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.

Yes. Sorry if I continue to believe that domain-based allow/deny
enforcement should be done on the server.

> * 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.

My guess is that my opinions are already known: I would prefer that servers
have to do something special to opt-in to transmission of cookies with a
cross-site request. I expect there will be scenarios where some sites
support POST without using cookies and some sites that naively use cookies
without proper session checking. I would prefer to err on the side of
carefulness. It isn't too much to ask a server developer to add an N+1th
header to enable cookies.

> * Investigate the random delay feature from JSONRequest. Please do start
> this as a separate thread.

OK

> * Some editorial changes to the spec to make it more explicit about
> various risks when opting into various features.

Yes, but I wouldn't discount these editorial changes. In this case (i.e.,
cross-site requests), education is important, and the spec will be an
important educational document.

>
> 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?

No, the browser most definitely MUST honor the information sent back from
the server. If a particular method is not allowed within a cross-site
request, the browser MUST not send that request. What I was saying is that
the server should not assume that the client is trustworthy and should not
rely on client enforcement and instead should check every subsequent
request.

>
> > 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?

Right. That's the only possible thing we can do about legacy servers.

Jon

>
> / Jonas