On Dec 13, 2009, at 10:14 AM, Mark S. Miller wrote:
On Sat, Dec 12, 2009 at 11:14 PM, Maciej Stachowiak <[email protected]>
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
