W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2017

Re: Improving CORS security

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 10 May 2017 12:21:16 +0200
Message-ID: <CADnb78jJdfPJf6i=cHJvDE-8k11QFEGYiYWoRRFkv0nc9_=5ew@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: James Kettle <james.kettle@portswigger.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, May 10, 2017 at 12:13 PM, Mike West <mkwst@google.com> wrote:
> On Tue, May 9, 2017 at 5:41 PM, James Kettle <james.kettle@portswigger.net>
> wrote:
>> - Enabling static trust of multiple origins by supporting a
>> space-separated list of origins

It should be comma-separated, if anything. Space has historical
meanings and isn't really the way to combine multiple HTTP header
values.


>> - Enabling static trust of all subdomains by supporting the use of partial
>> wildcards like https://*.example.com

That actually makes verification a lot harder. Currently we can just
compare the byte sequences.


>> Trusting the 'null' origin is equivalent to trusting * except it's less
>> obviously risky, and actually more dangerous since the allow-credentials
>> exception for * doesn't apply to null. I think it may be helpful to apply
>> the allow-credentials exception to 'null'.
>
> For clarity, you're suggesting that `Access-Control-Allow-Origin: null`
> should not be allowed if the request included credentials (in the same way
> that we block `Access-Control-Allow-Origin: *`)? I think I could get behind
> that, depending on usage in the wild.

It's been an open issue for a while:
https://fetch.spec.whatwg.org/#cors-check. Nobody ever got the data or
made the change though.


>> Websites accessed over HTTPS can use CORS to grant credentialed access to
>> HTTP origins, which partially nullifies their use of HTTPS. Perhaps
>> browsers' mixed content protection should block such requests, or at least
>> disable allow-credentials for HTTP->HTTPS requests.
>
> Interesting. You're suggesting that `https://example.com/` should not be
> able to send `Access-Control-Allow-Origin: http://whatever.com`? That sounds
> reasonable on the one hand, but I suspect that it's widely used on the other
> (all (I hope) Google API endpoints are HTTPS, for example, but not all of
> those APIs' clients will be). I'll add some metrics to Chrome to see if that
> suspicion is borne out.

Yeah, this would also make transitioning to HTTPS harder. Since now
you can't just update your CDNs first and gradually shift your
frontend. It all becomes tightly coupled.

Seems more reasonable as a new "I share with secure contexts only" feature.


-- 
https://annevankesteren.nl/
Received on Wednesday, 10 May 2017 10:21:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:23 UTC