On Oct 13, 2009, at 5:31 PM, Mark S. Miller wrote:
On Mon, Oct 12, 2009 at 10:49 PM, Adam Barth <w...@adambarth.com>
wrote:
[...] We should concentrate on the following questions:
1) Does CORS introduce security vulnerabilities into legacy servers
that are unaware of the CORS protocol?
2) How well does CORS support the simple use cases of cross-origin
resource sharing?
3) Does CORS prevent sophisticated developers from implementing
advanced uses cases?
Do you find CORS problematic for any of the above questions? Do you
think we should be concerned with other questions?
The issue is either #2 or "other question" depending on how you look
at it. Let's look at this by analogy.
The analogy is interesting, but what's the problem CORS itself has?
Can you give an example of a #2 problem, or state the "other question"
we should be concerned with and why CORS scores poorly by that metric?
Say we rewind the web prior to
the introduction of cookies. Say that web already had cookieless
cross-origin form GETs and POSTs. Say cookies were now being proposed
in this forum, together with the proposal that cookies be conveyed by
those cross-origin form GETs and POSTs. As we now know, this mistake
resulted in a confused deputy vulnerability, CSRF, that is now
understood to be a big deal.
How would an objection in this forum to the introduction of
cross-origin cookies have fared at that time by the above criteria?
1) Do cross-origin cookies introduce security vulnerabilities into
legacy servers
that are unaware of the cross-origin cookie protocol?
Since no one yet pays any attention to cookies, adding cookies can't
create any vulnerabilities in legacy servers. (And also like CORS,
since legacy clients don't send it, it doesn't create any new
vulnerabilities for them either).
2) How well do cross-origin cookies support the simple use cases of
cross-origin
resource sharing?
As we all now know, many simple use cases are supported well by
cross-origin cookies.
Actually, we now all know that many (most?) simple use cases are not
supported well by cross-origin cookies without some additional
mechanism beyond the basic-pre-existing platform, since they would be
subject to a CSRF vulnerability. You could argue that in the
hypothetical world, no one could have predicted this. But I think at
the time cookies were introduced, no one seriously tried to predict
the vulnerabilities. This was before the same-origin security model
was formulated; there was considerably less understanding of Web
security. Cookies first shipped before JavaScript.
If CORS has similar vulnerabilities in simple use cases, then in the
non-hypothetical present day we should be able to predict them.
3) Do cross-origin cookies prevent sophisticated developers from
implementing
advanced uses cases?
Clearly not. Adding ignorable cookies doesn't prevent anyone from
doing anything they can now do.
Q: Do you find cross-origin cookies problematic for any of the above
questions?
Apparently not, but I have a nagging feeling that I answer #2 too
quickly.
Q: Do you think we should be concerned with other questions?
Yes. Returning from the hypothetical, since we now understand how
cross-origin cookies led to CSRF, and since none of the numbered
questions would have caught the problem before it was too late,
clearly we're missing something.
By this argument, do you mean to say something more specific than
"even simple use cases of CORS may have a currently unknown future
vulnerability"?
Regards,
Maciej
