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