[cap-talk] Open Review of the CORS Specification

[David-Sarah Hopwood]

Adam Barth wrote:
> On Mon, Oct 12, 2009 at 11:20 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>> Putting aside other problems, it is unclear why the preflight request
>> is needed, given that the current same-origin policy does not (in most
>> cases) prevent a cross-origin request from being *made*;
> 
> The pre-flight request is meant to prevent attackers from being about
> to issue requests they cannot currently issue.

So just prevent them from issuing requests that they cannot currently issue.

The existing same-origin policy already allows cross-origin *requests* --
with some minor restrictions that are not worth fixing. The restriction
that needs to be relaxed, in a secure way, is that the policy does not
allow cross-origin *responses* to be read by the requesting page.

There are two important considerations to relaxing this restriction
securely:

 - 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.

 - 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.

>> it only attempts
>> to prevent the response from being read. So the assertion in the "Design
>> Decision FAQ" section that 'The "permission to make the request" check is
>> performed because deployed servers do not expect such cross-origin
>> requests.' is nonsense, at least for GET requests and for POST requests
>> that could occur by form submission.
> 
> 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.

> 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.

> For example, the Google Web Toolkit uses this mechanism.  If we were
> to forgo the pre-flight request in these cases, we would create
> vulnerabilities in legacy servers.

I was not suggesting anything that would create vulnerabilities in
existing servers; I was suggesting that the restrictions on *requests*
should stay exactly as they are. That is not the important thing to fix.

>> The example of DELETE is spurious --
>> who cares about DELETE enough to introduce this extra message for all
>> HTTP methods?
> 
> I've personally built web applications that rely on the fact that
> DELETE requests cannot be sent cross-origin.

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

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com