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

On Dec 17, 2009, at 1:42 AM, Kenton Varda wrote:

> 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).

I'm not saying that Alice should be restricted in who she shares the  
feed with. Just that Bob's site should not be able to automatically  
grant Charlie's site access to the feed without Alice explicitly  
granting that permission. Many sites that use workarounds (e.g. server- 
to-server communication combined with client-side form posts and  
redirects) to share their data today would like grants to be to  
another site, not to another site plus any third party site that the  
second site chooses to share with.

> 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.

An automated permission grant system that vends unguessable URLs could  
just as easily manage the whitelist. It is true that app developers  
could not unilaterally grant access to other origins, but this is  
actually a desired property for many service providers. Saying that  
this feature is "cumbersome" for the service consumer does not lead  
the service provider to desire it any less.

> (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.

Hiding capability URLs completely from the user would require some  
mechanism that has not yet been proposed in a concrete form. So far  
the ways to vend the URL to the service consumer that have been  
proposed include user copy/paste, and cross-site form submission with  
redirects, both of which expose the URL. However, accidental  
disclosure by the user is not the only risk.

> So, I don't think this "additional defense" is really worth much,  
> unless you are arguing that cookies are insecure for the same reasons.

Sites do, on occasion, make mistakes in the algorithms for generating  
session cookies. Or for that matter for CSRF-prevention secret tokens.  
Cookies have some protections that explicit secret tokens do not.  
First, there is no need to ever embed them in a page. This means they  
are not prone to be revealed to attacks that can observe the page  
content but not intercept network traffic or inject script. CSS  
injection is an example of such an attack vector. Secret tokens are  
often embedded via <input type="hidden"> or in URI-containing  
attributes on elements in the DOM.

Second, Cookies can further be as HttpOnly, which makes them invisible  
to script, in such cases even a full XSS exploit cannot steal the  
cookie (short of some additional exploit to get the victim server to  
reflect it back).

Finally, session cookies can be transparently reissued as often the  
origin server cares to, thus limiting the time window for a potential  
attack based on stealing them.

Now, similar protections could be provided for capability tokens. It's  
hard to evaluate that kind of idea in the abstract, without a concrete  
proposal. But I have a hard time seeing how to do it other than by the  
browser adding tokens to requests passively, and collecting them from  
the service provider passively. However, that would create a form of  
ambient authority and thus presumably would miss the point.

Sites also have a stronger incentive to protect their own cookies (to  
defend their own resources) than they do to protect capability tokens  
received from a third party (which merely protect some third party's  
resource).

>  (Perhaps we should only allow users to use approved browsers  
> because other browsers might leak cookie data?)

Users generally are expected have a trust relationship with their  
browser that they do not need to have with random sites they browse  
to. Browsers have the security model of native software, i.e. they can  
do anything the user does, whereas Web pages are run in a very  
restrictive sandbox.

That being said, some sites do lock out particular browsers, or  
threaten to, if they feel the browser's security is inadequate to  
protect their users. Typically this has been financial institutions.

> 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.

If there are costs as well as benefits is not the same as "no  
benefit". I don't believe you have even demonstrated that the costs  
exceed the benefits, at least from the point of view of the service  
provider.

Regards,
Maciej