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

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? If so,
then I agree. One major weakness of JSONRequest is that it only supports
JSON. It would have been a better proposal if it were named something like
DataRequest and supported arbitrary content (which of course would have
some ripple effects on the technology). The proponents of JSONRequest argue
back that JSONRequest does support XML, just that it has to be wrapped in
JSON: {xml:"<foo>hello</foo>"}, which is technically true, but clearly
inconvenient. To me, the main reasons why JSONRequest is interesting are:
(1) Simple, (2) Supports the primary requirement of enabling cross-site
requests, (3) Designed with security in mind, (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.

>
> 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. As I have said several times
before, AC has the wrong fundamental approach because it puts allow/deny
processing on the client rather than having the server do this. The server
already knows what policy it wants to enforce since it sends down the
Access-Control header or PI. Because of the client-side allow/deny
processing, AC has grown to be much more complicated than either
JSONRequest or XDR.

You have pointed out the JSONRequest doesn't support XML, and maybe you
will respond with other problems you see with JSONRequest (such as how it
never sends cookies). This mailing list has been flooded with complaints
about XDR's lack of flexibility, and how this will encourage developers to
do nasty workarounds which will compromise the very security benefits
behind XDR's approach. Therefore, it probably does not make sense to
rubberstamp either JSONRequest or XDR, but my feeling is that it would be
better to put everyone in a room and start from either JSONRequest or XDR
(with their focus on conservatism and security) and then add flexibility
incrementally (with the security experts in the room or on the call). So,
that's just a high-level suggestion. The one detailed suggestion that I
would make is that whenever flexbility is added, then make sure that the
server has to opt-in to that extra feature and that the spec warns of
security dangers with enabling that feature. For example, don't transmit
cookies by default, but do allow cookies to be transmitted if the server
opts-in.

>
> > <jonas>
> > We can't make existing already deployed servers to start
> > dealing with this new spec.
> > </jonas>
> >
> > I'm not sure what you are asking. Are you saying that we can't require
> > existing servers to make changes in order to support cross-site
> > requests? But AC also requires servers to make changes in order to
> > support at least some of its features.
>
> I simply meant that we can't create a spec which makes currently
> deployed servers suddenly vulnerable. I.e. we have to use an opt-in
> mechanism rather than an opt-out one.

We agree on this one!

>
> / Jonas
>