CVE-2023-23913

What it actually does

A DOM-based Cross-Site Scripting (XSS) vulnerability exists in the rails-ujs component of Ruby on Rails. The flaw occurs because the library does not properly sanitize HTML content pasted from the clipboard into an element with the `contenteditable` attribute. If an attacker can convince a user to paste specially crafted HTML containing `data-method`, `data-remote`, or `data-disable-with` attributes, it can lead to the execution of arbitrary JavaScript in the context of the user's browser session on the affected website.

Why it matters to the business

Exploitation of this vulnerability can lead to the compromise of user accounts, theft of sensitive data visible to the user, and unauthorized actions performed on behalf of the user. This can result in loss of user trust, reputational damage, and potential regulatory issues if sensitive user information is compromised. The requirement for user interaction (pasting content) lowers the risk compared to a zero-click vulnerability, but the impact on an affected user can still be significant.

How an attack unfolds

An attacker first crafts a malicious HTML snippet containing attributes like `data-remote="true"` and `data-url="[attacker-controlled-script]"`. They then use social engineering tactics to persuade a user of a vulnerable Rails application to copy this snippet to their clipboard. The user, believing the content to be benign, then pastes it into a rich text editor or another `contenteditable` field within the application. The rails-ujs library, failing to sanitize the pasted content, processes these special `data-*` attributes, triggering the execution of the attacker's script in the user's browser. This script can then be used to steal session cookies, exfiltrate data from the page, or perform actions as the user.

How to fix it

To remediate this vulnerability, developers should update their Ruby on Rails applications to a version that includes the security patch. The fix was introduced in commit `5037a13614d71727af8a175063bcf6ba1a74bdbd`. Review your application's dependencies and update the `rails` gem to the latest secure version that incorporates this patch.

How to confirm the fix worked

To validate the vulnerability, set up a test environment with the application and create a page with a `contenteditable` element. Copy an HTML snippet like `<div data-remote="true" data-url="/some-endpoint" href="/some-endpoint">Test</div>` to your clipboard and paste it into the editable area. Monitor the browser's network requests. If a request is made to `/some-endpoint`, the application is vulnerable. A patched version should strip or neutralize these `data-*` attributes upon pasting, preventing the request. Ensure your application's `rails` version includes commit `5037a13614d71727af8a175063bcf6ba1a74bdbd` or a later fix.

Typical attack path

1. An attacker crafts malicious HTML content containing special `data-*` attributes designed to execute code.
2. The attacker uses a social engineering lure (e.g., a forum post, email, or chat message) to convince a target user to copy the malicious HTML snippet.
3. The user navigates to a vulnerable Ruby on Rails application and pastes the content into a `contenteditable` field, such as a comment box or profile editor.
4. The unsanitized content is processed by the rails-ujs library on the client-side.
5. The malicious `data-*` attributes are triggered, causing arbitrary JavaScript to execute in the victim's browser within the security context of the application.
6. The attacker's script steals the user's session token or performs other malicious actions.

How to detect it

Detecting exploitation of this DOM-based XSS is challenging as the initial attack occurs entirely within the user's browser. Server-side logs will not show the exploit itself. However, post-exploitation activity may be detectable. Analyze web server and WAF logs for unusual or anomalous requests originating from a legitimate user's session, such as rapid API calls or attempts to access endpoints inconsistent with normal user behavior. On the client side, EDR or proxy logs might show the compromised browser making outbound connections to unknown or malicious domains if the payload attempts to exfiltrate data.

What your security team should do

• Identify all applications using the Ruby on Rails framework and determine if they utilize the `rails-ujs` component with `contenteditable` fields.
• Prioritize patching for public-facing applications and applications that handle sensitive data, especially those with rich text editing features.
• Update affected applications to a version of Rails that incorporates the security fix from commit `5037a13614d71727af8a175063bcf6ba1a74bdbd`.
• As a defense-in-depth measure, review and strengthen your Content Security Policy (CSP) to restrict where scripts can be loaded from and executed, which can help mitigate the impact of XSS vulnerabilities.