https://bz.apache.org/bugzilla/show_bug.cgi?id=62343
Bug ID: 62343
Summary: CORS security: reflecting any origin header value when
configured to * is dangerous
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: whu...@gmail.com
Target Milestone: ----
What's the Problem?
When CORS policy is configured to "Origin:*" and "Credentials:true"(default
setting), current Tomcat CORS filter 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[1-5].
Why is that?
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.
How to fix?
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, instead of return any origin header value.
Some similar security issues:
[1] https://github.com/cyu/rack-cors/issues/126
[2] https://nodesecurity.io/advisories/148
[3] https://github.com/yiisoft/yii2/issues/16193
Some related blog posts:
[4]
http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
[5] https://ejj.io/misconfigured-cors/
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
