On Dec 12, 2009, at 7:17 PM, Adam Barth wrote:
On Thu, Dec 10, 2009 at 12:04 PM, Jonas Sicking <[email protected]>
wrote:
On Thu, Dec 10, 2009 at 10:53 AM, Arthur Barstow <[email protected]
> 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
