Re: Scientific Literature on Capabilities (was Re: CORS versus Uniform Messaging?)

Somehow I suspect all this has been said many times before...

On Wed, Dec 16, 2009 at 11:45 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> CORS would provide at least two benefits, using the exact protocol you'd
> use with UM:
>
> 1) It lets you know what site is sending the request; with UM there is no
> way for the receiving server to tell. Site A may wish to enforce a policy
> that any other site that wants access has to request it individually. But
> with UM, there is no way to prevent Site B from sharing its unguessable URL
> to the resource with another site, or even to tell that Site B has done so.
> (I've seen papers cited that claim you can do proper logging using an
> underlying capabilities mechanism if you do the right things on top of it,
> but Tyler's protocol does not do that; and it is not at all obvious to me
> how to extend such results to tokens passed over the network, where you
> can't count on a type system to enforce integrity at the endpoints like you
> can with a system all running in a single object capability language.)
>

IMO, this isn't useful information.  If Alice is a user at my site, and I
hand Alice a capability to access her data from my site, it should not make
a difference to me whether Alice chooses to access that data using Bob's
site or Charlie's site, any more than it makes a difference to me whether
Alice chooses to use Firefox or Chrome.  Saying that Alice is only allowed
to access her data using Bob's site but not Charlie's is analogous to saying
she can only use approved browsers.  This provides a small amount of
"security" at the price of greatly annoying users and stifling innovation
(think mash-ups).

Perhaps, though, you're suggesting that users should be able to edit the
whitelist that is applied to their data, in order to provide access to new
sites?  But this seems cumbersome to me -- both to the user, who needs to
manage this whitelist, and to app developers, who can no longer delegate
work to other hosts.

(Of course, if you want to know the origin for non-security reasons (e.g. to
log usage for statistical purposes, or deal with compatibility issues) then
you can have the origin voluntarily identify itself, just as browsers
voluntarily identify themselves.)


> 2) It provides additional defense if the "unguessable" URL is guessed,
> either because of the many natural ways URLs tend to leak, or because of a
> mistake in the algorithm that generates unguessable URLs, or because either
> Site B or Site A unintentionally disclose it to a third party. By using an
> unguessable URL *and* checking Origin and Cookie, Site A would still have
> some protection in this case. An attacker would have to not only break the
> security of the secret token but would also need to manage a "confused
> deputy" type attack against Site B, which has legitimate access, thus
> greatly narrowing the scope of the vulnerability. You would need two
> separate vulnerabilities, and an attacker with the opportunity to exploit
> both, in order to be vulnerable to unauthorized access.
>

Given the right UI, a capability URL should be no more leak-prone than a
cookie.  Sure, we don't want users to ever actually see capability URLs
since they might then choose to copy/paste them into who knows where, but
it's quite possible to hide the details behind the scenes, just like we hide
cookie data.

So, I don't think this "additional defense" is really worth much, unless you
are arguing that cookies are insecure for the same reasons.  (Perhaps we
should only allow users to use approved browsers because other browsers
might leak cookie data?)

And again, this "additional defense" has great costs, as described above.

So, no, I still think CORS provides no benefit for the protocol I described.
 It may seem to provide benefits, but the benefits actually cost far more
than they are worth.