Re: CORS versus Uniform Messaging?

On Dec 13, 2009, at 10:14 AM, Mark S. Miller wrote:

> On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
> 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.
>
> Please read again the CORS spec and the Uniform Messaging spec.  
> Which one has the greater risk of "complexity-induced implementation  
> mistakes"?

To clarify, I mean complexity in implementing a defense using the  
mechanism, as opposed to complexity involved in implementing the  
mechanism in the browser.

>
> As one example, the CORS preflight uses a duration to indicate how  
> long the browser may cache an opt-out. But a duration from when?  
> Server programmers will most naturally assume, from when the message  
> was sent. After this period of time, they can consider the access  
> granted by a preflight to be revoked, and to take action predicated  
> on that revocation. More sophisticated server programmers will try  
> to take clock skew and network latency into account -- despite the  
> fact that CORS recommended server behavior never even mentions these  
> hazards. However, as we know, an adversary in the network can delay  
> https responses. How long can these responses be delayed? Frankly, I  
> have no idea. Before CORS, I had no reason to worry about this issue.

Good point. I can think of a couple of ways to handle this:

1) The spec could say that severs should not count on preflight  
information expiring at any particular time, except relative to the  
cache lifetime of subsequent responses. This is likely to be a  
sufficiently strong condition in most cases. I don't believe an  
attacker can selectively choose which https responses to delay.

2) Expiration for the preflight could be specified as an absolute time  
(in GMT) instead of as a delta, then clock skew may be a factor, but  
latency or artificial delay may not be.

> In any spec as complicated as CORS, there are likely to be many more  
> such vulnerabilities. This one was found without much effort.

Let's find them then.

>
> - 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.
>
>
> Please. I'm very interested.

All right. I'll need to make some diagrams and I'm pretty busy with  
end-of-year stuff, so I may not get a chance to send this until after  
the holidays.

Regards,
Maciej