Re: [cors] unaddressed security concerns

On Oct 9, 2009, at 4:36 PM, Mark S. Miller wrote:

>
> The last of the links above should make the application to CORS
> concrete. See also the dismissive replies which followed in that
> thread. If you find these dismissals plausible, please imagine back to
> the world in which CSRF was first diagnosed (second bullet above) as
> ask if CSRFs would have also seemed merely theoretical back then? In
> both cases, the answer "well don't do that" seems to make sense on
> first analysis for the same reasons.

Tyler claimed the vulnerability in his example could be avoided by not  
identifying the origin of a cross-site request, but he did not explain  
how. For example, if photo.example.com instead used a shared secret to  
identify itself to strage.example.com, the exact same scenario could  
occur.

I would argue that the vulnerability here is created by using a URI to  
identify an access-controlled resource on a third-party site. Some  
ways to safely perform the transaction include:

1) printer.example.net asks storage.example.org for a one-time write  
access token for its per-user job spool (perhaps indicating that  
photo.example.com is the only site authorised to use it), and hands it  
to photo.example.com, which then uses it to write. It can't tell  
photo.example.com to overwrite a different photo, because it cannot  
acquire a write access token for that photo. CORS can help implement  
this approach - it knows which part of a user's space is writable to  
printer.example.net, and can use the Origin header to decide that  
printer.example.net

2) storage.example.org can offer a "conditional write" service that  
copies a file only if all parties listed in the request, plus those  
listed in Origin, have write access. Then when photo.example.com  
uploads a photo for spooling on behalf of printer.example.net, it can  
list printer.example.net as one of the domains that must have write  
access.

Either of these approaches works fine with CORS. Thus, I do not see  
how the scenario argues against providing the Origin header.

I am sure there are solutions that do not use the Origin header at  
all, solely using one-time token schemes. However, popular one-time  
token schemes for cross-origin networking typically require a shared  
secret, and thus cannot be done client-to-server. Thus, no form of  
cross-origin client-side networking is helpful for implementing them.

CORS is helpful in these kinds of multi-party scenarios because it  
allows you to bootstrap a secret token scheme from the client side, by  
using the combination of Origin and a user credential such as a cookie  
to grant the initial token, based on the user's pre-existing access  
grants, and without the need for a shared secret between the two sites  
that are party to the transaction.

Regards,
Maciej

Received on Monday, 12 October 2009 14:05:22 UTC