Re: CORS versus Uniform Messaging?

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"?

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.

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



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

-- 
   Cheers,
   --MarkM