|
| 1 | +--- |
| 2 | +gem: phlex |
| 3 | +cve: 2024-32970 |
| 4 | +ghsa: 9p57-h987-4vgx |
| 5 | +url: https://github.com/phlex-ruby/phlex/security/advisories/GHSA-9p57-h987-4vgx |
| 6 | +title: Phlex vulnerable to Cross-site Scripting (XSS) via maliciously |
| 7 | + formed HTML attribute names and values |
| 8 | +date: 2024-05-01 |
| 9 | +description: | |
| 10 | + There is a potential cross-site scripting (XSS) vulnerability that |
| 11 | + can be exploited via maliciously crafted user data. |
| 12 | +
|
| 13 | + The reason these issues were not detected before is the escapes were |
| 14 | + working as designed. However, their design didn't take into account |
| 15 | + just how recklessly permissive browser are when it comes to executing |
| 16 | + unsafe JavaScript via HTML attributes. |
| 17 | +
|
| 18 | + ### Impact |
| 19 | +
|
| 20 | + If you render an `<a>` tag with an `href` attribute set to an |
| 21 | + user-provided link, that link could potentially execute JavaScript |
| 22 | + when clicked by another user. |
| 23 | +
|
| 24 | + ```ruby |
| 25 | + a(href: user_profile) { "Profile" } |
| 26 | + ``` |
| 27 | +
|
| 28 | + If you splat user-provided attributes when rendering any HTML or SVG |
| 29 | + tag, malicious event attributes could be included in the output, |
| 30 | + executing JavaScript when the events are triggered by another user. |
| 31 | +
|
| 32 | + ```ruby |
| 33 | + h1(**JSON.parse(user_attributes)) |
| 34 | + ``` |
| 35 | +
|
| 36 | + ### Patches |
| 37 | +
|
| 38 | + Patches are [available on RubyGems](https://rubygems.org/gems/phlex) |
| 39 | + for all minor versions released in the last year. |
| 40 | +
|
| 41 | + - [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2) |
| 42 | + - [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3) |
| 43 | +
|
| 44 | + If you are on `main`, it has been patched since |
| 45 | + [`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2) |
| 46 | +
|
| 47 | + ### Workarounds |
| 48 | +
|
| 49 | + Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) |
| 50 | + that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) |
| 51 | + would effectively prevent this vulnerability from being exploited. |
| 52 | +
|
| 53 | + ### References |
| 54 | +
|
| 55 | + In addition to upgrading to a patched version of Phlex, we strongly |
| 56 | + recommend configuring a Content Security Policy header that does |
| 57 | + not allow `unsafe-inline`. Here’s how you can configure a Content |
| 58 | + Security Policy header in Rails. |
| 59 | + https://guides.rubyonrails.org/security.html#content-security-policy-header |
| 60 | +cvss_v3: 7.1 |
| 61 | +patched_versions: |
| 62 | + - "~> 1.9.3" |
| 63 | + - ">= 1.10.2" |
| 64 | +related: |
| 65 | + url: |
| 66 | + - https://nvd.nist.gov/vuln/detail/CVE-2024-32970 |
| 67 | + - https://github.com/phlex-ruby/phlex/security/advisories/GHSA-9p57-h987-4vgx |
| 68 | + - https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2 |
| 69 | + - https://rubygems.org/gems/phlex |
| 70 | + - https://rubygems.org/gems/phlex/versions/1.10.2 |
| 71 | + - https://rubygems.org/gems/phlex/versions/1.9.3 |
| 72 | + - https://github.com/payloadbox/xss-payload-list |
| 73 | + - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy |
| 74 | + - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline |
| 75 | + - https://github.com/advisories/GHSA-9p57-h987-4vgx |
0 commit comments