Re: [cors] unaddressed security concerns

On Oct 13, 2009, at 5:31 PM, Mark S. Miller wrote:

> On Mon, Oct 12, 2009 at 10:49 PM, Adam Barth <w3c@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

Received on Wednesday, 14 October 2009 02:48:19 UTC