Phoenix 1.3, 1.4, 1.5, and 1.6 security releases for wildcard check_origin vulnerability

Phoenix 1.3.5, 1.4.18, 1.5.14, and 1.6.14 have been released to resolve a vulnerability in wildcard check_origin configurations.

Previously, our documentation points to a wilcard example of:

check_origin: [
  "//*.other.com"
]

Which should allow any subdomain of “other.com”, but our comparison for "//*.other.com" would allow api.any-other.com, which would allow an attacker to register a domain with a custom prefix of a target domain and pass origin checks. These releases ensures the host comparison only matches subdomains or the host itself.

Who is affected?

Only those using a wildcard check origin are affected, and potential exploits are limited allowing unauthenticated channel connections from a bad host. Because LiveView adds its own csrf token to the connection by default, LiveView applications with wildcard check origin would refuse connection under this scenario. Additionally, channel applications utilizing token based authentication would require the attacker to also have a valid token to connect from a bad host. Phoenix channels does not allow access to cookies, so an attacker would also not be able to pass their own cookies from a bad host.

If you are unable to upgrade to a new version, a workaround to mitigate the issue is to use an extra . in your wildcard, such as "//*..other.com"

Thank you to James Van Lommel at Semsee for disclosing this vulnerability and working with us to establish a fix.

–Chris

60 Likes

Hey @chrismccord can you clarify if we have to upgrade and change the pattern to “//*…other.com” or if we upgrade we don’t have to change it?

1 Like

If you upgrade, you must not change the pattern to "//*..other.com". Doing so means it would allow foo..other.com but not foo.other.com.

7 Likes

Thank you, that’s clear now.

1 Like