There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.
Since the last two vulnerabilities GHSA-242p-4v39-2v8g and GHSA-g7xq-xv8c-h98c, we have invested in extensive browser tests. It was these new tests that helped us uncover these issues.
We now exercise every possible attack vector we can think of — including enumerating every ASCII character, and we run these tests in Chrome, Firefox and Safari. Additionally, we test against a list of 6613 known XSS payloads.
The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.
Impact
If you render an <a>
tag with an href
attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.
a(href: user_profile) { "Profile" }
If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.
h1(**JSON.parse(user_attributes))
Patches
Patches are available on RubyGems for all minor versions released in the last year.
If you are on main
, it has been patched since da8f943
Workarounds
Configuring a Content Security Policy that does not allow unsafe-inline
would effectively prevent this vulnerability from being exploited.
References
In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow unsafe-inline
. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.
Since the last two vulnerabilities GHSA-242p-4v39-2v8g and GHSA-g7xq-xv8c-h98c, we have invested in extensive browser tests. It was these new tests that helped us uncover these issues.
We now exercise every possible attack vector we can think of — including enumerating every ASCII character, and we run these tests in Chrome, Firefox and Safari. Additionally, we test against a list of 6613 known XSS payloads.
The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.
Impact
If you render an
<a>
tag with anhref
attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.
Patches
Patches are available on RubyGems for all minor versions released in the last year.
If you are on
main
, it has been patched sinceda8f943
Workarounds
Configuring a Content Security Policy that does not allow
unsafe-inline
would effectively prevent this vulnerability from being exploited.References
In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow
unsafe-inline
. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header