GHSA-CWV4-H3J5-W3CF: Stored and Reflected Cross-Site Scripting in rama's Directory Listing Component

The rama library is a modular Rust-based web service framework designed for building performant services, proxies, and web applications. Within its HTTP module, rama-http, the library provides a ServeDir service to serve static files directly from a designated directory on the filesystem. When configured with DirectoryServeMode::HtmlFileList, the service dynamically generates HTML index documents to list directory contents for client browsers.

The vulnerability lies within the file rendering logic located in rama-http/src/service/fs/serve_dir/open_file.rs. Because the directory-listing feature dynamically constructs the HTML document using direct string manipulation, it creates an attack surface vulnerable to Cross-Site Scripting (XSS). An attacker capable of injecting files, modifying filenames, or manipulating URL paths can execute arbitrary web scripts in the security context of the application's origin.

This security weakness is classified under CWE-116 (Improper Encoding or Escaping of Output). Under specific environmental conditions, such as applications that support user-driven file uploads or shared directory mounts, this issue escalates from a localized vector to a network-reachable threat vector. The impact ranges from session hijacking to administrative takeover depending on the exposed web application's permission model.

The fundamental root cause of GHSA-CWV4-H3J5-W3CF is the improper escaping of user-controlled inputs before rendering them inside dynamic HTML outputs. In affected versions of rama, the template construction relies on the native Rust format! macro to combine static HTML boilerplate with active data variables. These variables include physical file or directory names read from the filesystem as well as requested URI path segments directly extracted from client HTTP requests.

The directory listing service processes the local filesystem contents by reading DirEntry structures. The name of each entry, exposed via entry.name, is interpolated directly into both the text of the link and the href attribute of the generated anchor tag. Because the library fails to sanitize or escape HTML entities (such as <, >, ", ', and &), the browser interprets characters inside the filename as structure-defining HTML markup rather than plain text.

Similarly, request URI paths are sliced and formatted directly into the <title> and <h1> tags of the index page to display breadcrumbs and header titles. An attacker who crafts a specific HTTP request path containing script tags can exploit the application's reflection of that path back into the HTML stream. Consequently, the flaw presents two distinct injection vectors: a stored vector utilizing manipulated filesystem names, and a reflected vector utilizing crafted HTTP request paths.

To understand the mechanics of the vulnerability, we analyze the vulnerable file row rendering code in rama-http/src/service/fs/serve_dir/open_file.rs before the fix. The generation of each table row representing a filesystem entry was performed using the following string interpolation block:

// VULNERABLE CODE PATH
rows.push(format!(
    "<tr><td>{5} <a href=\"{1}{2}{0}\">{0}</a></td><td>{3}</td><td>{4}</td></tr>",
    entry.name,
    uri.path().trim_end_matches('/'),
    if uri.path().trim_start_matches('/').is_empty() {
        ""
    } else {
        "/"
    },
    modified_str,
    hs,
    emoji,
));

In this block, entry.name corresponds to {0}. It is placed directly inside the double-quoted href string and also as the inner HTML anchor text. If entry.name contains a double quote ("), it breaks out of the href attribute context. The attacker can then inject event handlers such as onerror or onload directly into the anchor element.

Furthermore, the breadcrumbs navigation construction demonstrates the same structural vulnerability:

// VULNERABLE BREADCRUMBS PATH
nav_parts.push(format!("<a href=\"{current_path}\">{part}</a>"));

To remediate this, the patch implemented in commit 89ddff578fd78bbebec99482d7030f28c07757a3 refactors the HTML construction. It extracts all generation logic to a secure module (open_file_html.rs) and replaces format! with structured rendering macros:

// SECURE CODE PATH (From Commit 89ddff5)
let mut link = base_link.clone();
link.path_mut().push_segment(entry.name.as_str());
let href = link.to_string();
 
tr!(
    td!(emoji, " ", a!(href = href, entry.name)),
    td!(modified),
    td!(size),
)

The use of push_segment ensures that URI-unsafe characters in the filename are percent-encoded within the href attribute. Additionally, the macro-based layout engine automatically escapes raw HTML characters in entry.name using the internal escape_and_write implementation, neutralizing any embedded payload tags.

Exploitation of the stored variant requires that an attacker have the ability to write files or directories to the directory served by ServeDir. This is typical in environments hosting user-upload directories, file share attachments, or shared container volumes. An attacker initiates the exploit by creating a file with a specifically crafted name that contains HTML and JavaScript payload components.

# Creating a directory structure containing the payload on the filesystem
mkdir -p /var/www/uploads/rama-xss-test
cd /var/www/uploads/rama-xss-test
touch '"><img src=x onerror=alert(document.domain)>.txt'

When an authenticated victim or administrator navigates to the corresponding path mapping on the web service, the rama directory listing engine reads /var/www/uploads/rama-xss-test. It dynamically renders the directory listing page. The backend generates raw HTML output and transmits it to the victim's browser. Because the href attribute is prematurely closed by the double quote character in the filename, the browser interprets the subsequent payload as an active HTML element and triggers script execution.

The operational impact of this vulnerability depends on the configuration of the web application and the permissions assigned to the executing origin. Because the script executes in the client's browser under the origin of the web application, it gains full access to the Document Object Model (DOM). In a typical configuration, this permits the extraction of sensitive authorization tokens stored in localStorage or sessionStorage as well as non-HttpOnly session cookies.

Additionally, the script can perform silent actions on behalf of the active user. If an administrator visits the directory listing page, the malicious script can interact with the application's administrative APIs to alter application configurations, create rogue accounts, or exfiltrate sensitive backend database credentials. In enterprise environments with shared file repositories, a single low-privileged user uploading a malicious file name could compromise the accounts of all other repository users.

While the official CVSS score is rated Low (3.7) due to local complexity vectors in restricted systems, the operational vector in public-facing applications presents a higher risk profile. If an application exposes a directory listing mapping to user-supplied contents, the threat model escalates to an unauthenticated, network-accessible cross-site scripting path. In such deployments, the risk is closer to Medium (6.5) because it demands no prior local terminal access to write payload files.

The primary remediation path is the immediate upgrade of the rama dependency to version 0.3.0-rc.1 or higher. The update replaces raw formatting logic with secure HTML macro-level abstractions and ensures all filenames undergo proper encoding. The Cargo dependency entry must be updated to reference the patched version:

[dependencies]
rama = "0.3.0-rc.1"

If upgrading is not immediately viable, the vulnerability can be mitigated by disabling the HTML directory listing mode in the service configurations. By default, ServeDir should be configured to return a 404 Not Found error or a generic 403 Forbidden page instead of generating interactive HTML. This is achieved by setting the directory serve mode explicitly:

use rama_http::service::fs::{ServeDir, DirectoryServeMode};
 
let service = ServeDir::new("static-directory")
    // Disable dynamic HTML directory listing output
    .with_directory_serve_mode(DirectoryServeMode::NotFound);

Additionally, organizations should audit directories exposed by ServeDir to ensure they do not accept unvalidated user uploads. If user uploads are necessary, strict filename sanitization must be enforced at the application boundary to reject filenames containing control characters.