Re: Are we making a Category Mistake?

On Sat, Dec 19, 2009 at 8:05 PM, Adam Barth <w3c@adambarth.com> wrote:

> I'm not interested in being drawn into another one of these threads.
>

I don't understand. If you're not interested, would you rather I reply or
not?


> The issue you're worried about here is several orders of magnitude
> (100x? 1000x?) less likely than XSS.  XSS blows away an semblance of
> isolation between service A and service B.  Put another way, A and B
> already have to coordinate about all the other shared resources in
> their origin.  For example, they share the same localStorage.
>
> Adam
>
>
> On Sat, Dec 19, 2009 at 6:51 PM, Mark S. Miller <erights@google.com>
> wrote:
> > On Sat, Dec 19, 2009 at 5:58 PM, Adam Barth <w3c@adambarth.com> wrote:
> >>
> >> Mark,
> >>
> >> The difference is subtle, but important.
> >
> > Indeed.
> >
> >>
> >> I'm leery of starting
> >> another centithread on CORS, but I'll try my best to explain clearly
> >> in a single email:
> >>
> >> 1) On the client, if two URLs are within the same origin, they share a
> >> common security context.  This is because a document located at the
> >> first URL can inject script into a document located at the second URL.
> >>  By injecting script into the second document, the first document is
> >> able to do anything the second document can do.  Therefore, we cannot
> >> grant different privileges to different URLs in the same origin.
> >
> > Although we agree that Caja asks us to revisit assumption #1 as you point
> > out below, that is not the issue I am raising here. Without tech like
> Caja,
> > and therefore without revisiting assumption #1, I agree that we cannot
> > support mutual suspicion within an origin. Under these baseline
> assumptions,
> > if any service within the origin is malicious, all other services within
> the
> > origin are vulnerable to it. Therefore, that is not the case I am
> concerned
> > about here, just as it is not the case motivating the per-resource
> preflight
> > in CORS.
> > I thought Anne stated the form of loose coupling within an origin that is
> a
> > concern quite well. Repeating:
> >
> > We are concerned that a per-origin model would not be implemented
> correctly.
> > In addition it would be somewhat of a pain in case of different services
> > maintained by different parties hosted on a single origin which we expect
> to
> > be reasonably common.
> >
> > And that is why in my response, I stated "For the same reason, we are not
> > *serving the interests* of an origin by adding that origin's name to the
> ACL
> > for a resource." [emphasis added] Say that grantor G seeks to grant
> > to service A at origin O permission P to access resource R. Say G does
> this
> > using the path of least resistance suggested by the CORS mechanism (and
> > repeatedly suggested as a sound practice in this thread) -- by adding O
> to
> > R's ACL. If service B at origin O is malicious, it can certainly steal P,
> so
> > that is not my present concern.
> > Rather, if A and B are both "services maintained by different parties
> hosted
> > on a single origin" O, where A and B are politely trying to stay out of
> each
> > other's way, then G inadvertently disrupts the correct operation of B by
> > causing permission P to be applied to B's requests merely as a side
> effect
> > of trying to grant P to A. This does not serve the interests of B, nor of
> > the origin serving as the host for such mutually trusting but separately
> > maintained services.
> > If G grants permission P to A by communicating authorizing information to
> A,
> > that A can choose to present or not when making a request, then if A and
> B
> > are coordinating, A can communicate this authorization to B, for B to
> > present, as part of the A-to-B coordination. A's permission P applies to
> B
> > when A and B arrange for it to. When they do not, it does not.
> >
> >
> >>
> >> 2) On the server, we have no such restriction.  That's why can we
> >> grant different access to different URLs within the same origin via
> >> XMLHttpRequest.
> >>
> >> For these reasons, CORS lets site operators assign different access
> >> policies to different URLs on the server but requires all URLs in the
> >> same origin to be granted thee same privileges on the client.
> >>
> >> Whether or not we prefer to live in a world where (1) is not the case,
> >> that's the world in which we currently live.  Some emerging
> >> technologies, like Caja, ask us to revisit assumption (1), which is
> >> one of the use cases for UM.  In these cases, the document containing
> >> the Caja gadget is going to great lengths to keep the gadget from
> >> accessing a number of objects that it could use to breach containment.
> >>  The container can simply grant access to UM and to block access to
> >> XMLHttpRequest.
> >
> > Agreed. That is my plan once UM is deployed. But this is relevant only to
> my
> > case for UM -- which seems undisputed. It is not relevant to my case
> against
> > CORS.
> > --
> >    Cheers,
> >    --MarkM
> >
>



-- 
   Cheers,
   --MarkM