Rack CORS is fundamentally insecure.

[ejcx]

Rack CORS has a fundamental problem. Setting origin: '*' should return a "Access-Control-Allow-Origin: *" and should not reflect the origin header.

Defaulting to Access Control Allow Credentials: true is also inherently insecure, and when combined with this unexpected reflection of the origin header means thousands of sites have "turned off" SAMEORIGIN policy.

Why should it be like this?
Because origin:* means that Credentials should never be passed to the cross origin site. The way you are doing it, developers who mean to set Access-Control-Allow-Origin: * (safely) are getting unexpected unsafe behavior that allows their credentials to be sent cross origin.

What should happen instead?
Origin: "" should return an Access-Control-Allow-Origin: header, instead of a reflected origin header.

It should not be possible to reflect the origin header, as there is no real use case for this that is not covered by Access-Control-Allow-Origin: *.

[ejcx]

Just to give a little more detail.

https://github.com/cyu/rack-cors/blob/master/lib/rack/cors.rb#L359
At 359, It will return "*" only if credentials is turned off, but credentials is on by default.

Credentials should be off by default, because people setting a "*" policy without knowing the default are reflecting the Origin header with Credentials true.

This is not intuitive at all, and I'm seeing thousands of sites make this mistake.

[cesc1989]

Agreed. I've been recently fighting an issue with CORS and preflight requests over an Nginx server and learnt that Access-Control-Allow-Credentials: true can't go along with Access-Control-Allow-Origin: * because an error is raised:

Response to preflight request doesn't pass access control check: A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin '' is therefore not allowed access. The credentials mode of an XMLHttpRequest is controlled by the withCredentials attribute.

Issue #95 also asks about setting Access-Control-Allow-Credentials: true by default.

[jensvoid]

Stumbled over this one when i wanted to file an issue for exactly the same thing.

Rack::Cors maps origins '*' into reflecting arbitrary origins; this is dangerous, because developers would think that "*" behaves according to the spec: mostly harmless because it cannot be used to make to make 'credentialed' requests; this leads to origin reflection with Access-Control-Allow-Credentials headers if the example configuration is used.

Had been looking for reasons of CORS misconfiguration in the scope of an analysis for the Alexa top 1m websites when is stumbled over Rack::Cors often being used in vulnerable websites. As it seems, lots of sites actually apply the example config or trust "*" to behave according to the spec.

Should really be fixed.

[peret]

I opened a PR for this. The overall goal of this PR is to make the default/example configuration more secure.

This is a breaking change for:

1. Users who use the default configuration and do rely on the insecure behavior for some reason.
2. Users who explicitly set credentials: true in combination with a wildcard origin.

Disclaimer: Even with the PR it's still possible to have an insecure configuration with this gem, e.g. by specifying a super-generic Regex like /(.*)/ as the origin. However, the example config will be secure.

I would love feedback on the fix and whether this is the best way to go. Either way, let's move this thing forward quickly, please :)

[cyu]

Thanks @ejcx @peret and everyone else for doing the heavy lifting on this. I'm working on putting this and a couple of other breaking fixes together for a 1.0.

Is there any posts that thoroughly discusses this issue? I want to add it to the readme.

[kimroen]

Here's a post that might be helpful: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

[jensvoid]

Our large scale analysis of CORS misconfigurations blogpost (mentioning Rack::Cors a major cause):
http://web-in-security.blogspot.de/2017/07/cors-misconfigurations-on-large-scale.html

[ejcx]

@jensvoid . Your research, inspired by James Kettle's, is inspired by my research of the alexa top 1m.... I did this over 1.5 years ago now!

Funny how things repeat:
https://ejj.io/misconfigured-cors/

[ejcx]

Also @peret way to take the initiative. I'm not rubyist and couldn't figure it out.