Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

(Warning - rehashing discussion that has been stated previously)

Hi Ian,
Yes, it is true that the browser implements some level of policy
enforcement due to its same-domain policy. This is a very good things for
the Web. However, the focus of the PEP discussion is about the extending
the browser to support cross-domain policy decisions, not the same-domain
policy decisions which exist in today's browsers. IMO, those cross-domain
decisions about who can GET or POST data should be enforced by the server,
not by a technique (used in AC) where the server passes its policy to the
client (along with the data) and hopes the client will enforce that policy.
I don't think it is a positive that AC splits the cross-domain policy
enforcement between client and server. Rather than the best of both worlds,
it is unnecessarily complex. The proponents of AC have contended that CSRF
protection can still happen on the server even though AC does some policy
enforcement on the client. Since the server needs to do the heavy lifting
for CSRF protection anyway, I think it is better to use the simpler
approaches found in JSONRequest or XDR where the client's role in policy
enforcement is minimized, along the lines of JSONRequest or XDR.

Jon

public-appformats-request@w3.org wrote on 04/14/2008 01:06:09 PM:

>
> On Mon, 14 Apr 2008, Jon Ferraiolo wrote:
> > Thomas Roessler <tlr@w3.org> wrote on 04/14/2008 08:21:50 AM:
> > > On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote:
> > >
> > > > On the architecture side, Access Control is just plain wrong, with
> > > > the PEP on the client instead of the server, which requires data to

> > > > be sent along the pipe to the client, where the client is trusted
to
> > > > discard the data if the user isn't allowed to see the data; it is
> > > > just plain architecturally wrong to transmit data that is not meant

> > > > to be seen.
> > >
> > > This seems to confuse the attacker model a bit.  It's not about the
> > > user not being permitted to see the data, it's about a web
application
> > > from a different origin not being allowed to manipulate the data,
even
> > > though the user is allowed to see the data.
> >
> > The comment in question wasn't about CSRF or other data-setting attacks

> > on a server, but instead about how it is architecturally wrong to send
> > data that ultimately will be thrown out when it reaches the client. If
I
> > was outside of the standards world and wrote some code that did this, I

> > would be embarrassed to show such an implementation during a code
> > walkthrough. The policy check should be done before the data is
> > transmitted.
>
> XDR also has the PEP on the client side. There haven't been any
> suggestions as to how to put the PEP on the server while still blocking
> access to existing deployed servers.
>
> Note that AC actually does support having a PEP on the server-side as
well
> if that is desired. So it's the best of both worlds -- it supports
> existing servers as well as providing for a server-side PEP.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>