Re: Improving CORS security

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
exploitable).
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.
Evan


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