Workout Journal App 1.0 - Stored XSS

Workout Journal App 1.0 — Stored XSS (CVE-2024-24050)

This article explains the stored Cross-Site Scripting (XSS) vulnerability reported in Workout Journal App 1.0 (CVE-2024-24050). It covers what the vulnerability is, how it arises, its impact, and practical, secure fixes and mitigations for developers and system owners. Examples are in PHP since the application is PHP/MySQL-based.

What is Stored XSS?

Stored XSS occurs when an attacker is able to persist malicious script content on a server (for example, in a profile or comment) and that content is later rendered by the application into a web page without proper output encoding. When other users (or the same user) load that page, the browser executes the injected script in the context of the victim page, enabling cookie theft, session hijacking, DOM manipulation, or other malicious actions.

Why this app is vulnerable (root cause)

• The application accepts user-supplied values (first_name, last_name, etc.) and stores them in the database.
• When rendering the landing/home page, those stored values are injected into the HTML without output encoding or sanitization, allowing embedded HTML/JS to execute in users' browsers.
• The core issue is not storage per se but rendering untrusted data directly into HTML context. Proper defenses require output encoding, input validation, and optional additional layers like CSP.

Impact

• Execution of arbitrary JavaScript in users' browsers under the application's origin.
• Potential theft of cookie-based sessions (if cookies are not HttpOnly), CSRF token leakage, or unauthorized actions performed in victim sessions.
• Reputation damage, data exposure, and further pivoting attacks against application users.

Safe Reproduction Summary (for testers)

During testing, registrable fields that are later rendered on the home page were found to be reflected verbatim into HTML. This allowed a stored script to be persisted and triggered when viewing the home page. Reproduction requires responsible handling and authorization; avoid publishing or using real malicious payloads outside controlled lab environments.

Secure Fixes and Best Practices

1) Output encoding (primary defense)

Always escape user-supplied data on output consistent with the HTML context. For content placed into HTML element body or attributes, use proper encoding. In PHP, htmlspecialchars is recommended for HTML contexts.

<?php
// Rendering the user's first and last name safely on the home page:
echo 'Welcome ' . htmlspecialchars($user['first_name'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')
     . ' '
     . htmlspecialchars($user['last_name'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
?>

Explanation: This code uses htmlspecialchars to convert special characters (<, >, &, quotes) into safe HTML entities before output. ENT_QUOTES ensures both single and double quotes are encoded. ENT_SUBSTITUTE helps prevent invalid encoding issues. UTF-8 is explicitly declared to avoid charset mismatches.

2) Input validation and canonicalization (complementary)

Validate input to enforce expected formats (lengths and allowed characters). For names, an allowlist approach is stronger than blacklist filtering.

<?php
// Example validation for a first/last name: allow letters, spaces, hyphens, and apostrophes
$raw_first = $_POST['first_name'] ?? '';
$raw_last  = $_POST['last_name']  ?? '';

$first_valid = preg_match("/^[\p{L}\p{M} '-]{1,100}$/u", $raw_first);
$last_valid  = preg_match("/^[\p{L}\p{M} '-]{1,100}$/u", $raw_last);

if (! $first_valid || ! $last_valid) {
    // Handle invalid input: reject or normalize and inform the user
    die('Invalid name format.');
}
$first_name = trim($raw_first);
$last_name  = trim($raw_last);
?>

Explanation: This regex allows Unicode letters (\p{L}), marks (\p{M}), spaces, hyphens, and apostrophes, with max length protection. Validation reduces the likelihood of unexpected characters being stored, but it is not a substitute for output encoding.

3) Use parameterized queries when storing data

Always use prepared statements to prevent SQL injection; although not directly related to XSS, it's fundamental for secure storage.

<?php
// PDO prepared statement example for safe insertion
$pdo = new PDO('mysql:host=localhost;dbname=workout', 'user', 'pass', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
]);

$stmt = $pdo->prepare('INSERT INTO users (first_name, last_name, email, username, password_hash) VALUES (?, ?, ?, ?, ?)');
$password_hash = password_hash($_POST['password'], PASSWORD_DEFAULT);
$stmt->execute([$first_name, $last_name, $_POST['email'], $_POST['username'], $password_hash]);
?>

Explanation: This code uses PDO with prepared statements to safely insert user data into the database. It also demonstrates hashing passwords with password_hash. Prepared statements prevent injection; hashing protects credentials.

4) Set secure cookie flags

Protect session cookies by setting Secure and HttpOnly flags, and use SameSite where appropriate.

<?php
// Recommended session configuration
session_set_cookie_params([
    'lifetime' => 0,
    'path' => '/',
    'domain' => 'example.com', // set to your domain or omit for default
    'secure' => true,          // true if using HTTPS
    'httponly' => true,
    'samesite' => 'Lax',
]);
session_start();
?>

Explanation: HttpOnly prevents JavaScript from reading cookies; Secure ensures cookies are only sent over HTTPS; SameSite reduces CSRF risk. These settings reduce the impact of XSS attacking session cookies.

5) Content Security Policy (CSP) — additional mitigation

Implement a strict CSP to limit script sources and disallow inline scripts where feasible. Note: migrating away from inline scripts may require refactoring templates to use non-inline handlers.

<?php
// Example header to help mitigate XSS: disallow inline scripts and only allow trusted script sources
header(\"Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com; object-src 'none'; base-uri 'self';\");
?>

Explanation: This CSP blocks inline scripts ('unsafe-inline') and only allows scripts from the same origin and a trusted CDN. CSP is a defense-in-depth measure — do not rely on it as the sole control.

Testing and Verification

• Use security scanners (e.g., OWASP ZAP, Burp Suite) to find XSS vectors in form inputs, stored content, and different output contexts (HTML element, attribute, JS, URL).
• Manually review templates that render user-supplied values — ensure every insertion point performs context-appropriate encoding.
• Test cookie flags and CSP with browser developer tools and security headers scanners.
• Perform regression tests after fixes to ensure legitimate content still renders correctly and UX is preserved.

Developer Checklist (quick)

Area	Action
Storage	Use prepared statements; retain raw user data if needed, but do not assume it's safe to render unencoded.
Output	Encode for the specific context (html entity-encode for HTML, JS-encode for inline JS contexts, URL-encode for URLs).
Input	Validate and normalize; prefer allowlists for structured fields.
HTTP	Enforce HTTPS; set Secure, HttpOnly, and SameSite on cookies.
Headers	Apply CSP, X-Content-Type-Options, Referrer-Policy, and other security headers.

Responsible Disclosure and Remediation Timeline

If you are a provider or maintainer of this project, follow a responsible disclosure lifecycle: privately notify the vendor or project maintainers, allow reasonable time to patch, coordinate disclosure of CVE and public advisory, and provide guidance or patches to users. Since this issue has an assigned CVE, ensure the advisory includes remediation steps and recommended version updates.

Conclusion — Key Takeaways

• Stored XSS arises when untrusted data is rendered without appropriate encoding. Output encoding is the essential defense.
• Combine output encoding with input validation, secure storage practices, cookie hardening, and CSP for layered protection.
• Test comprehensively and deploy fixes with clear guidance for users and maintainers.