Hospital Management System v1.0 - Stored Cross Site Scripting (XSS)

Hospital Management System v1.0 — Stored Cross‑Site Scripting (XSS) (CVE-2024-29412)

Summary

This article examines a stored Cross‑Site Scripting (XSS) issue reported in Hospital Management System v1.0 (CVE-2024-29412). The vulnerability allows user-supplied data in patient fields to be stored and later rendered in the receptionist UI without proper encoding, which can lead to execution of arbitrary JavaScript in the context of authenticated users.

Vulnerability overview

• Type: Stored (persistent) Cross‑Site Scripting (XSS)
• Affected component: receptionist.php — patient information form fields (patient_id, first_name, middle_initial, last_name)
• Impact: Session theft, actions performed on behalf of the victim, local UI manipulation, possible pivot to further attacks (CSRF amplification, data exfiltration)
• CVE: CVE-2024-29412

How the vulnerability arises (root cause)

The application accepts user input for patient-related fields and stores it into the database. When those fields are rendered back into HTML (for example in a patient list or detail view), the values are output directly into the page without context‑aware HTML escaping or sanitization. This makes it possible for an attacker to inject scripting content that will execute in other users’ browsers when they view that data.

Proof‑of‑Concept (high‑level, non‑executable)

In general terms, a stored XSS POC for this class of issue follows this pattern: an attacker submits data that contains HTML/JavaScript into an application field that is persisted. Later, when another user visits the page that displays that stored field, the content is injected into the DOM and the browser executes the script content.

Example of the pattern (HTML‑escaped so it cannot execute here): <script>alert('X')</script> — submitted into a patient field, persisted, and later rendered without escaping.

Real‑world impact and abuse cases

• Steal authentication cookies or tokens (if not protected by HttpOnly and secure cookie attributes).
• Perform actions on behalf of a logged‑in receptionist (create/modify patient records, trigger sensitive workflows).
• Conduct targeted phishing inside the application UI (display fake dialogs or forms).
• Exfiltrate patient data by sending it to attacker‑controlled endpoints.

Detection and verification (safe, defensive approaches)

• Code review: search for unescaped outputs. Look for patterns that directly echo database fields into HTML templates, e.g., echo $row['first_name'];
• Static scanning: run SAST tools or grep for occurrences of print/echo/printf/print_r where values come from request or database without escaping.
• Dynamic scanning (defensive): use authenticated scanners (OWASP ZAP, Burp) to detect reflected/stored XSS, but avoid publishing exploit details.
• Logging and monitoring: audit input values inserted into patient tables for suspicious HTML tokens (script, onerror, onload) and alert on their presence.

Secure coding and immediate remediation steps

Fixes should be applied server‑side first; client‑side filtering alone is not sufficient. Key remediation principles:

• Context‑aware output encoding: escape data based on where it is inserted (HTML element content, attribute, JavaScript context, URL).
• Input validation and whitelisting: accept only permitted character sets and formats for IDs and names.
• Use prepared statements for database operations (preventing injection classes and clearer data handling).
• Defensive headers: set Content‑Security‑Policy (CSP), set cookies with HttpOnly, Secure and SameSite flags.
• Sanitization libraries: use well‑maintained libraries (server‑side HTML sanitizers or frameworks) when rich text is required.

Example — vulnerable vs. secure output in PHP

<?php
// Vulnerable: direct output of DB fields without escaping
echo "<td>" . $row['first_name'] . "</td>";
?>

Explanation: This code prints a database column straight into HTML. If the database value contains HTML or JavaScript, the browser will interpret it.

<?php
// Secure: context‑aware escaping using htmlspecialchars
echo "<td>" . htmlspecialchars($row['first_name'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8') . "</td>";
?>

Explanation: htmlspecialchars converts special characters to HTML entities (for example < becomes &lt;). This prevents injected HTML/JS from being interpreted by the browser when rendered inside element content. ENT_QUOTES ensures both single and double quotes are escaped; ENT_SUBSTITUTE prevents invalid UTF‑8 from breaking output.

Example — safe database insert with prepared statements

<?php
// Use PDO prepared statements to insert safely
$stmt = $pdo->prepare(
  'INSERT INTO patients (patient_id, first_name, middle_initial, last_name) VALUES (?, ?, ?, ?)'
);
$stmt->execute([$patient_id, $first_name, $middle_initial, $last_name]);
?>

Explanation: Prepared statements avoid SQL injection and keep a clear separation between data and SQL. They do not by themselves prevent XSS — you must still escape when outputting.

Additional mitigations (defense‑in‑depth)

• Content Security Policy: reduce risk by restricting where scripts can load and execute. Example header:

  Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';

  Explanation: CSP can mitigate the impact of injected scripts (depending on policy strictness), especially if inline scripts are disallowed.

• HttpOnly and Secure cookies: prevent client‑side script from reading session cookies if server sets these flags.
• DOM sanitization for any client‑side HTML rendering: use trusted libraries like DOMPurify when you must allow some HTML.
• WAF rules: deploy Web Application Firewall signatures to block common payload patterns as an additional layer (not a replacement for fixing the code).

Testing & hardening checklist

• Audit all places that print user or DB values into HTML — ensure they use context‑aware escaping.
• Prefer templating systems that auto‑escape by default (Twig, Blade, etc.).
• Ensure forms validate and normalize allowed input for patient_id and name fields (whitelisting where possible).
• Implement logging and alerts when suspicious HTML tokens are submitted to sensitive tables.
• Deploy CSP and verify behavior across browsers; tune to block inline scripts and untrusted origins.
• Regressively test after patching: use authenticated dynamic scanners to verify stored XSS is closed.

Responsible disclosure and patch guidance

If you maintain the affected project:

• Prioritize a patch that adds output encoding and input validation to the receptionist patient views.
• Release a security advisory describing the vulnerability, affected versions, and recommended upgrade path.
• Coordinate disclosure timelines with any downstream projects or hosts that distribute the software.

References & further reading

• OWASP XSS Cheat Sheet — practical guidance for preventing XSS
• OWASP Secure Coding Practices — output encoding and validation recommendations
• Guides for Content Security Policy best practices and pitfalls