CORS security: reflecting any origin header value when configured to * is dangerous
chenjj opened this issue · 6 comments
When CORS policy is configured to origin:"*", current go CORS handler will actively convert it to reflect any Origin header value. This kind of behavior is dangerous and has caused many security problems in the past.
Some similar security issues:
cyu/rack-cors#126
https://nodesecurity.io/advisories/148
Some related blog posts:
http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
https://ejj.io/misconfigured-cors/
This is only the case when allow credential is enabled, which is not the default. What change would you expect?
Hi Olivier, thanks for your reply.
Yeah, setting credentials to false by default can reduce misconfigurations, but the point I want to say here is that, converting Origin: * and Credentials: true to origin reflection is insecure and incompatible with CORS standards.
Current CORS standards(both W3C CORS and WHATWG fetch standard) have a clear definition for the wildcard *, which means any domain is allowed. But they also have another important security requirement: Origin: * and Credentials: true cannot be used at the same time, to avoid overly loose permissions. Currently all browsers follow this requirement to disallow this configuration combination.
If a framework actively converts * to reflect any origin header value, it means Origin: * and Credentials: true can be used at the same time. This behavior leads to CORS protocol's security design to be bypassed, causing many misconfiguration security problems.
Therefore, I suggest frameworks to follow the standard definition of *. When a user configures Origin:*, frameworks just directly returns Access-control-Allow-Access: *. When a user configures both Origin:* and Credentials: true , frameworks should warn users that this is a misconfiguration because browsers will not accept this combination.
FYI, here are some more similar issues:
Yii2 framework, yiisoft/yii2#16193
Tomcat CORSFilter, CVE-2018-8014, https://bz.apache.org/bugzilla/show_bug.cgi?id=62343
Looks good, thanks!