[cap-talk] Open Review of the CORS Specification

[Adam Barth]

On Tue, Oct 13, 2009 at 11:21 AM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> So just prevent them from issuing requests that they cannot currently issue.

It sounds like you're advocating for the XDomainRequest API.  I agree
that is a reasonable design, and it has been deployed in at least one
major implementation.  For whatever reason, the WebApps working group
has decided they want to design a more featureful API.  I don't really
have the expertise to evaluate how much value these extra features
bring to the table.  Whether we should recommend XDomainRequest or
CORS is a trade-off between features and complexity.

>  - the server must opt in to revealing the response. If the set of
>   requests that can be made is not expanded, then it is safe for this
>   opt-in to be signalled just by a header in the response. That would be
>   much simpler than the pre-flight mechanism.

This is precisely how XDomainRequest works.

>  - the current cookie mechanism is prone to CSRF attacks due to its
>   use of ambient authority. That is, all cookies that are applicable
>   for the target server are sent, not only cookies that the requesting
>   page has access to and chooses to explicitly send to the target page.
>
>   Although this weakness is present in the same-origin case as well, in
>   that case it is typically only exploitable in combination with an XSS
>   vulnerability. If servers come to rely on the fact that all applicable
>   cookies are sent cross-origin (as they will if CORS is implemented as
>   it stands), then that will create many CSRF vulnerabilities exploitable
>   by attacks that do not also require an XSS vulnerability. So it would
>   be irresponsible to allow that without providing a solution to the
>   cookie ambient-authority problem, and ideally requiring that solution
>   to be used in the cross-origin case.

These paragraphs are confused.  XSS is not required to mount a CSRF
attack.  If you're not expanding the set of requests a malicious web
page can generate, then you're not creating more CSRF vulnerabilities.

>> You're right that a form submission can be sent cross-origin, but a
>> form submission cannot attach custom headers.
>
> So what? It's not necessary to attach custom headers. Relying on custom
> headers is contrary to the REST architecture: HTTP headers are protocol
> metadata, and using them for application-level data is a layering
> violation.

Not everyone subscribes to REST.  For whatever reason, many web sites
attach custom headers to XMLHttpRequests.  It seems reasonable that
these folks also want to attach headers to cross-origin
XMLHttpRequests.

>> There are many web sites that rely on custom headers to distinguish
>> same-origin requests from cross-origin requests.
>
> The headers are untrustworthy; you cannot safely use them for access
> control. Of course, this does not preclude that existing sites are
> unsafely using them for access control. If there continues to be no
> way to send custom headers in a form submission, this practice will
> be exactly as unsafe -- no more and no less -- as before. I see no
> clear justification for changing this.

Are you saying you know how to mount a CSRF attack against Google Web
Toolkit?  Based on what I know, they're use of custom headers as a
CSRF defense works great, i.e., they are sufficiently trustworthy for
this purpose.

> I meant, who cares about *allowing* cross-origin DELETEs enough to
> introduce this extra pre-flight message for all HTTP methods?

The pre-flight request is not made for all HTTP methods.  The
pre-flight request is made only for requests that cannot already be
generated by already-existing APIs.

Adam