Re: Improving CORS security

Sorry. I wanted to branch off the top comment. My mistake. Here is my
post
(tweaked and) re-sent.

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

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.

I see current CORS problems as less of an implementation problem and
more of a logic problem. People just don't understand "*" and explaining
it is not easy.

Evan


On Tue, May 9, 2017, at 08:41 AM, James Kettle wrote:
> Hi all,
> 
> After encountering a significant number of websites that have serious vulnerabilities due to their use of CORS, I'd like to float a few ideas for improvements to the CORS specification and its implementation in browsers.
> 
> Due to limitations in the CORS spec/implementation, numerous websites are forced to dynamically generate the access-control-allow-origin header based on the incoming Origin header. This creates a situation where websites have security-critical functionality based on parsing user input. We could reduce the number of sites forced to do dynamic generation by:
> 
> - Enabling static trust of multiple origins by supporting a space-separated list of origins
> - Enabling static trust of all subdomains by supporting the use of partial wildcards like https://*.example.com
> 
> 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'.
> 
> 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. 
> 
> 
> I've written a longer blog post on this topic over at http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html and I'll be presenting on this topic at AppSec EU on Friday so feel free to say hi if you're around.
> 
> Hopefully this is the right forum to present this ideas, and I'm not five years too late.
> 
> Cheers,
> 
> James Kettle
> 
>

Received on Friday, 12 May 2017 21:56:30 UTC