Re: CORS versus Uniform Messaging?

On Dec 12, 2009, at 7:17 PM, Adam Barth wrote:

> On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking <jonas@sicking.cc>  
> wrote:
>> On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow <Art.Barstow@nokia.com 
>> > wrote:
>>> Ideally, the group would agree on a single model and this could be  
>>> achieved
>>> by converging CORS + UM, abandoning one model in deference to the  
>>> other,
>>> etc.
>>>
>>> Can we all rally behind a single model?
>>
>> I'm not sure that we want to. My impression is that both models have
>> their advantages and risks. They basically implement two different
>> security design philosophies, and I'm not confident that there is a
>> winner, or that we can correctly pick one.
>
> I agree with Jonas.  It seems unlikely we'll be able to
> design-by-commitee around a difference in security philosophy dating
> back to the 70s.
>
>> CORS seems easier in the simpler cases when no website acts as a
>> deputy. UM seems less likely to cause confused deputy problems when a
>> website acts as a deputy and receives urls from third parties (either
>> by fetching them over the network, or by having third party code
>> running in their domain using something like caja).
>
> I also agree with Jonas on these points.  What might make the most
> sense is to let the marketplace decide which model is most useful.
> The most likely outcome (in my mind) is that they are optimized for
> different use cases and will each find their own niche.

I agree with Jonas and Adam as well. I think both models have their  
use cases. A few specific additional thoughts:

- Something like UM seems pretty important, probably essential, for  
running guest code if you are relying on origin-based security at all  
to protect some of your resources.
- UM may be sufficient for some patterns of cross-domain messaging,  
but is not necessarily the most convenient.
- UM isn't strictly necessary for multi-party messaging interactions;  
CORS works fine too, as long as you don't rely on the Origin header as  
the sole security mechanism.
- Building a shared-secret-based defense for the kinds of "semi- 
public" resources that Hixie has been discussing is likely to be  
overkill for the level of security actually required, to the point  
that the risk of making complexity-induced implementation mistakes may  
be greater than the risks you face from basing your security on origin  
checks.
- In many cases (not including guest code running in something like  
Caja, but including one-party form submission, simple two-party cross- 
domain communication, and complex multi-party communication) combining  
a secret token / shared secret based defense with an Origin check is  
likely to be more secure than either alone. I would even go so far as  
to make the following claims:
     (a) Given a reasonably secure shared-secret-based system, then  
other things being equal, adding Origin checks will not make your  
system less secure.
     (b) In many cases, adding Origin checks to such a system may make  
it more secure, in the sense that it is robust against more kinds of  
unexpected failures.

I'd be happy to expand on the last point in a separate email if anyone  
cares to see some more detail and some examples.

Regards,
Maciej

Received on Sunday, 13 December 2009 07:14:44 UTC