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

public-appformats-request@w3.org wrote on 05/15/2008 01:49:55 PM:

>
> Jon Ferraiolo wrote:
>  > public-appformats-request@w3.org wrote on 05/15/2008 08:42:42 AM:
>  > > Jon Ferraiolo wrote:
>  > > > <jonas>
>  > > > I don't understand at all what you are proposing. If we allow the
>  > > > client to always POST cross domain the damage is already done and
>  > > > we have lost already....JSONRequest always allows cross-site
>  > > > POSTs, I.e. it always allows the thing we are trying to prevent.
>  > > > </jonas>
>  > > >
>  > > > JSONRequest requires that a server make explicit changes in order
>  > > > to opt-in to enabling cross-site requests (GET or POST). From the
>  > > > JSONRequest spec (http://www.json.org/JSONRequest.html):
>  > > >
>  > > > 3. Reponses will be rejected unless they contain a JSONRequest
>  > > > content type. This makes it impossible to use JSONRequest to
>  > > > obtain data from insecure legacy servers.
>  > >
>  > > Yes, JSONRequest makes the assumption that POSTing data cross site
>  > > is safe as long as the posted data is of type
>  > > application/jsonrequest. This is an assumption that I personally as
>  > > well as mozilla feel very uncomfortable with.
>  >
>  > Why uncomfortable? Is it because JSONRequest only supports JSON?
>
> No, because performing cross-site POSTs before asking the receiving
> server first has lead to lots of CSRF problems in the past. This might
> be even worse if other methods, such as PUT and DELETE, are used. I'd
> much prefer the server was asked before making such a request.

Thanks. I had a side conversation with Kris Zyp about this and he expressed
the same concern as you.

As a general model, I am in favor of explicit server opt-in before any
transmission that might be unsafe. XHR/AC requires explicit server opt-in
(via handshaking over HTTP) before issuing a POST (or DELETE/PUT), whereas
JSONRequest and XDR do not require a prior handshake for POST. It does
indeed seem safer to me to use the XHR/AC approach for POST, although I can
see why Doug Crockford or Microsoft might disagree with this because people
often use the same server logic for both GET and POST. My opinion is that
we should challenge Microsoft to explain on this particular issue why they
think XDR is more secure than what is in AC.

>
>  > (4) Improves incrementally from common practice today for
>  > cross-site requests, where today dynamic SCRIPT elements pull JSON
>  > data down from servers. But it isn't perfect.
>
> The fact that cross site <script> works today is really scary for many
> reasons. It's something that I really hope we can figure out a way to
> limit in the future.
>
> So it's definitely not a security model I want to build future security
> architecture on.

Yes, sure. In fact, I have been waiting for someone to propose a way to
make the browser *more* restrictive in terms of cross-domain activities.
One (probably overly simple) solution is some data in the original content
that tells the browser to only allow cross domain requests to a particular
whitelist of domains, even for images and stylesheets. We describe the
requirement (but not any good solutions) at:
http://www.openajax.org/runtime/wiki/Better_Security_for_Cross-site_Scripts.
 We are hoping that an HTTP expert within one of the browser teams will
become aware of this requirement and then propose a solution to the
community.

>
>  > > This become even more of a problem if you want to scale up the
>  > > JSONRequest spec to support other data types than JSON objects
>  > > (something which is in the AC requirements).
>  > >
>  > > That said, if you really think that it is possible to create a
>  > > security model based on JSONRequest which supports the requirements
>  > > listed in the AC spec, I look forward to such a proposal.
>  >
>  > Actually, even if there were no AC activity, I wouldn't expect the W3C
>  > to rubberstamp JSONRequest for two main reasons: (1) No XML support in
>  > JSONRequest, (2) There are probably various other improvements that
>  > would be needed to address requirements.
>  >
>  > But in my opinion JSONRequest or XDR would be good starting points for
>  > cross-site request technology that would have the right security
>  > characteristics and meet the requirements.
>
> The fact that JSONRequest is only able to transfer JSON data seems to be
> an center part of its security model. Especially when it comes to
> protecting data behind firewalls.

Yes

>
> However, as I said, would be interested to see a proposal based on
> JSONRequest. I would like to see that before getting the whole group
> together in an effort to build something based on JSONRequest, since I'm
> not convinced it is feasible.

I'm not sure it is feasable either to transform JSONRequest and having be
recognizable as a derivative spec. It probably would be easier and more
understandable to start with XDR and add key things from AC. Here is a
sketch that I'll submit and then I'll quickly duck. Basically define
something new that takes the union of all of the security features from all
of the proposals. I might have various details wrong, but the thrust of
this idea is a neutral proposal that unifies all of the proposals for
safeguards.

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

As I said earlier, I expect that there are some mistakes in the proposal
above. The only reason why I even tried was in case it might prove useful
to offer a strawman compromise/unification proposal.

>
> / Jonas
>