- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 10 May 2017 12:21:16 +0200
- 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