Re: Improving CORS security

Hi James,

Nice post! I've started working with OWASP Secure Headers Project for the
same reason. I saw a lot of websites defining the ACAO dynamically but most
of them were protecting the resources with a CSRF token.
One thing that I noticed when I was researching is that IE11 totally ignore
CORS specification for local files (https://github.com/riramar/IE11xCORSxSOP)
different from Chrome and Firefox. Microsoft said this is not a issue.
The problem is that you can trick the user with XSS using a FileAPI (
https://msdn.microsoft.com/en-us/library/hh772331(v=vs.85).aspx) to save a
html local file, open this file, do any request to any domain and send the
content to a domain you control. Of course the user needs to click on Save,
Open and Allow blocked content buttons but with a good phishing this is not
a big deal.
Another problem that I've noticed some times is about this point mentioned
in the CORS specification (ref. https://www.w3.org/TR/cors/#security):

Because of this, resources for which simple requests have significance
other than retrieval must protect themselves from Cross-Site Request
Forgery (CSRF) by requiring the inclusion of an unguessable token in the
explicitly provided content of the request.

CSRF is possible due a legacy cross-domain operations using POST forms for
example (ref.
https://en.wikipedia.org/wiki/Same-origin_policy#Corner_cases_and_exceptions).
Not sure if the CORS simple request is more "open" than these legacy
cross-domain operations but most of the developers/sysadmins don't know
about this problem described on the CORS specification. SameSite (
https://tools.ietf.org/html/draft-west-first-party-cookies-07) is a good
solution for CSRF but I didn't check how it's going to work with CORS in
this case.
I was trying to find an improvement for this protection in this case.
Instead of using CSRF tokens let's say that the server can identify that
the request is a CORS simple request so instead of processing the request
and send the CORS headers back it could just send back a not allowed.

Thanks!
Ricardo Iramar

On Tue, May 9, 2017 at 12:41 PM, James Kettle <james.kettle@portswigger.net>
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
>
>
>