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

Re: Improving CORS security

From: Evan J Johnson <e@ejj.io>
Date: Fri, 12 May 2017 14:45:02 -0700
Message-Id: <1494625502.3222610.974941472.6001CD96@webmail.messagingengine.com>
To: public-webappsec@w3.org
Hi, I wanted to bring up a problem that hasn't been touched on.
(Hi James!)
Having hunted down dozens of libraries that implement the CORS spec
wrong, one problem I consistently see is people are misunderstanding
"*". I see, without fail, developers believing that "*" means to reflect
all origin headers. This leads to problems when ACAC is set to true.
Here are two examples:
 - https://github.com/cyu/rack-cors/issues/126
 - https://github.com/captncraig/cors/pull/10

I am re-scanning the Alexa 1M for CORS misconfigurations and you can
scan them yourself:https://github.com/ejcx/badcors-massscan

Among the sites with it misconfigured, bitbucket.org, theblaze.com,
adidas.com, uverse.com, appnexus.com, etc, etc. (granted, not all are
In my opinion a separate header for "ACAO: *" should be created to keep
this complexity away from people who need to include credentials and
share data. The way I see it, the CORS situation won't improve until
people can wrap their heads around it.

On Fri, May 12, 2017, at 11:18 AM, Daniel Veditz wrote:
> On Fri, May 12, 2017 at 10:20 AM, James Kettle
> <james.kettle@portswigger.net> wrote:>> I think this would need to support credentials for anyone to use it.
>> I agree that trusting all subdomains isn't really a great idea, but
>> it's a common use case and if you enforced a rule like '* must be
>> followed by .' you could help out the many sites making Zomato's
>> mistake of trusting literally everything that ends in zomato.com,
>> including notzomato.com> 
> Wildcards in CSP directives have this requirement (apart from
> standalone "*"). Completely reasonable.> 
>> Maybe mixed content was a poor choice of terminology. I think this
>> suggestion might have been misunderstood slightly. I'm suggesting
>> that an application that specifies ACAO: true and ACAO: <some HTTP
>> origin> should have the ACAC flag ignored. I don't see how this will
>> making upgrading sites to HTTPS harder, since as Anne said the
>> standard approach is to upgrade CDNs first and the application
>> afterward, and it's only applications that care about allowing
>> credentials.> 
> Does Google have any telemetry on how often http->https XHR/fetch
> explicitly request credentials? Mozilla mixed-content telemetry
> ignores insecure documents so we don't have any.> 
> -
> Dan VEditz
Received on Friday, 12 May 2017 21:45:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:01 UTC