Blood Bank & Donor Management System using v2.2 - Stored XSS

Blood Bank & Donor Management System v2.2: A Critical Stored XSS Vulnerability Exposed

Security vulnerabilities in healthcare management systems pose a significant risk, especially when they involve sensitive data like donor information and blood records. The Blood Bank & Donor Management System v2.2, developed by phpgurukul.com, has recently been flagged for a stored cross-site scripting (XSS) flaw — a critical issue that can compromise both user data and system integrity.

Understanding Stored XSS in Context

Unlike reflected XSS, where malicious scripts are triggered only on specific requests, stored XSS occurs when malicious code is permanently saved in a database or server-side storage. This means that every time a victim accesses the affected page, the script executes automatically — without requiring any user interaction beyond visiting the page.

In the case of the Blood Bank & Donor Management System, the vulnerability lies in the /admin/update-contactinfo.php endpoint. This page allows administrators to update contact details such as address, email, and phone number. However, due to inadequate input sanitization, user-supplied data is stored directly into the database without proper validation or escaping.

Exploit Demonstration: The Proof-of-Concept (PoC)

Attackers can leverage this flaw by injecting malicious payloads into the contact fields. The following example demonstrates how an attacker can trigger a JavaScript alert using a crafted input:

/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert('1') )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/\x3csVg/\x3e

This payload is designed to bypass basic filtering mechanisms by using obfuscation techniques such as:

• Using non-standard characters like ` and \ to disrupt parsing.
• Inserting comments (//) and closing tags () to mimic valid HTML.
• Employing /* */ and --!> to hide malicious code within comment blocks.
• Using \x3csVg to represent <svg in hexadecimal form, evading detection.

When the administrator saves this input into the database, the payload remains stored. Subsequently, when the public-facing index.php page loads the data, the malicious script executes in the browser context — triggering alert('1') and potentially enabling more advanced attacks like session hijacking or data exfiltration.

Impact and Risk Assessment

Attack Vector	Severity	Exploitation Difficulty
Stored XSS via contact info update	High	Low (requires admin access)
Session theft via JS injection	High	Medium (requires JavaScript manipulation)
Phishing or malware redirection	Medium	Medium (requires additional payload)

Although the exploit requires admin credentials, the risk is still substantial. A compromised admin account can lead to widespread exposure of donor data, unauthorized access to sensitive records, and potential reputation damage to the blood bank institution.

Technical Root Cause Analysis

The vulnerability stems from a lack of input validation and output encoding. Specifically, the system fails to:

• Sanitize user input using functions like htmlspecialchars() or htmlentities().
• Validate data types and length constraints for contact fields.
• Apply Content Security Policy (CSP) headers to restrict script execution.

For instance, in the update-contactinfo.php file, the following pseudo-code illustrates the flawed logic:

// Vulnerable code snippet (hypothetical)
$address = $_POST['address'];
$query = "UPDATE contact_info SET address = '$address' WHERE id = 1";
mysqli_query($conn, $query);

This code directly inserts user input into an SQL query without escaping — a recipe for SQL injection and XSS. Even if the data is stored in a non-HTML context, it may be rendered in HTML without proper encoding when displayed on index.php.

Recommended Remediation

To mitigate this vulnerability, developers should implement the following security best practices:

• Input Sanitization: Use htmlspecialchars() to escape special characters before storing or displaying data.
• Output Encoding: Always encode data when rendering in HTML contexts, especially for user-generated content.
• Whitelist Validation: Accept only known-safe formats (e.g., alphanumeric for phone numbers, email format validation).
• Content Security Policy (CSP): Deploy a strict CSP header to prevent inline scripts from executing.
• Role-Based Access Control (RBAC): Limit admin access to trusted users only, and enforce multi-factor authentication.

Corrected code example:

// Secure version
$address = htmlspecialchars($_POST['address'], ENT_QUOTES, 'UTF-8');
$query = "UPDATE contact_info SET address = ? WHERE id = 1";
$stmt = mysqli_prepare($conn, $query);
mysqli_stmt_bind_param($stmt, "s", $address);
mysqli_stmt_execute($stmt);

This version uses parameterized queries to prevent SQL injection and ensures HTML-safe output via htmlspecialchars().

Broader Implications for Healthcare Software

This case highlights a recurring issue in open-source healthcare applications: security is often an afterthought. Many free tools like the Blood Bank & Donor Management System prioritize functionality over security, making them attractive targets for attackers.

Organizations deploying such systems must:

• Conduct regular security audits.
• Apply patches and updates promptly.
• Use automated vulnerability scanners (e.g., OWASP ZAP).
• Train staff on secure coding practices.

Ultimately, protecting donor data isn’t just about privacy — it’s about trust, safety, and accountability in life-saving services.