Re: [beacon] CORS and Credentials questions.

On Wed, Jan 8, 2014 at 10:20 AM, Ilya Grigorik <igrigorik@google.com> wrote:
>
> On Wed, Jan 8, 2014 at 9:00 AM, doug.turner@gmail.com
> <doug.turner@gmail.com> wrote:
>>
>> What I understand is
>> (https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS):
>>
>> “””
>> Also, if POST is used to send request data with a Content-Type other than
>> application/x-www-form-urlencoded, multipart/form-data, or text/plain, e.g.
>> if the POST request sends an XML payload to the server using application/xml
>> or text/xml, then the request is preflighted.
>
> It'd be nice if we can avoid preflights.

Agreed. Though research is needed to determine if that's safe. See below.

> Out of curiosity, why is
> "text/plain" considered "safe" whereas "text/xml" is not? Seems completely
> arbitrary, and in practice why would I just not mark my XML payloads as
> text/plain to avoid extra roundtrip?

The reasoning is purely that web browsers for a long time has enabled
sending cross-origin requests containing almost arbitrary data using
the content-type "text/plain". This can be done using HTML markup
like:

<form action="http://bank.com/transfermoney.cgi" enctype="text/plain">

The concern is that there might be servers out there that when they
receive a request first checks that the request has the right content
type before they do any actual data processing.

For example, if transfermoney.cgi was written such that it expects
data to be sent to it in XML format using a same-origin XHR request,
it would check the content-type header is "text/xml" and immediately
return an error message if it was not. Such a check might not be added
as a security precaution, but would nonetheless end up working as a
CSRF protector.

Such a server would be exploitable if we allowed preflight-less
cross-origin requests with content-type set to "text/xml".

Now, this is all in theory. The interesting question is of course "are
there any such servers".

I have a vague recollection that at some point flash did allow
cross-origin POSTs with the Content-Type header set to arbitrary
values. And that it allowed this without first checking
crossdomain.xml (which is the flash equivalent of preflights). I also
have a recollection that this did in fact turn up one or two
exploitable servers. But memory is very hazy so nothing to rely on.
And I don't know if the outcome was that flash changed their policy,
or if the affected servers were changed. Or if they are still
exploitable :)

If flash does indeed still allow cross origin POSTs with arbitrary
Content-Type headers without crossdomain.xml opt-in, then I see no
reason for CORS to be more restrictive. I don't know if anyone has
checked lately.

However even if we can't rely on flash to pave the way here, the above
scenario seems highly theoretical. I'd love to simply ignore it.
Possibly browsers are willing to attempt a more relaxed policy for
CORS, for example by relaxing cross-origin XHR. You'd have to check
with your local browser developers' security team.

Removing this restriction from CORS is pretty orthogonal though

> Beacon in particular is a bit peculiar in that we don't expect to read the
> response, it's just a one way ping...

CORS Preflights are all about protecting against server side actions,
not about protecting data in the response. The response is protected
through the headers in the response itself.

So unfortunately Beacon is nothing special here.

/ Jonas

Received on Wednesday, 22 January 2014 01:17:47 UTC