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

On Dec 16, 2009, at 9:10 PM, Kenton Varda wrote:

> Without the benefit of full context (I only started following this  
> list recently), I'd like cautiously to suggest that the UM solution  
> to Ian's "challenge" seems awkward because the challenge is itself a  
> poor design, and UM tends to be more difficult to work with when  
> used to implement designs that are poor in the first place.
>
> Specifically -- and note that I'm not sure I follow all the details,  
> so I could be missing things -- it seems that the challenge calls  
> for site B to be hard-coded to talk to site A.  In a better world,  
> site B would be able to talk to any site that provides feeds in the  
> desired format.  In order for this to be possible, the user  
> obviously has to explicitly "hook up" site B to site A somehow.   
> Ideally, this "hook-up" act itself would additionally imply  
> permission for site B to access the user's data on site A.  The  
> natural way to accomplish this would be for an unguessable access  
> token to be communicated from site A to site B as part of the "hook- 
> up" step.  Once such a mechanism exists, UM is obviously the best  
> way for site B to actually access the data -- CORS provides no  
> benefit at this point.

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

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.

Regards,
Maciej

Received on Thursday, 17 December 2009 07:46:35 UTC