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

Re: Improving CORS security

From: Mike West <mkwst@google.com>
Date: Wed, 10 May 2017 12:57:02 +0200
Message-ID: <CAKXHy=eNX5VdzyGggWKVTQHvKndDXJ6j3fga0wM0SE=oRD_X0w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: James Kettle <james.kettle@portswigger.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, May 10, 2017 at 12:21 PM, Anne van Kesteren <annevk@annevk.nl>
wrote:

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

Makes sense to me.

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

I agree, but it's not clear to me that that would be fatal, since browsers
that support CSP already have code to deal with this kind of wildcard
syntax.


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

Adding metrics for these two in https://codereview.chromium.org/2873973002.
I share Anne's skepticism about the latter, but let's get numbers and then
argue about them.

-mike
Received on Wednesday, 10 May 2017 10:57:58 UTC

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