Re: Are we making a Category Mistake?

I'm not interested in being drawn into another one of these threads.
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
>

Received on Sunday, 20 December 2009 04:06:09 UTC