Listen to this Post
Introduction:
DOM-based Cross-Site Scripting (XSS) represents one of the most elusive and dangerous web application vulnerabilities, as it occurs entirely client-side where traditional security scanners often fail. Unlike reflected or stored XSS, DOM XSS vulnerabilities emerge when JavaScript execution dynamically modifies the page’s Document Object Model using attacker-controllable data, creating exploitation scenarios that evade server-side detection and require deep understanding of client-side code execution.
Learning Objectives:
- Understand the fundamental mechanics of DOM XSS and why it evades traditional security testing
- Master manual detection techniques for identifying DOM XSS vectors without automated scanners
- Learn to weaponize DOM XSS findings with proof-of-concept exploits that demonstrate real impact
You Should Know:
1. Why DOM XSS Evades Traditional Security Scanners
DOM XSS vulnerabilities occur entirely client-side, meaning the malicious payload never travels to the server in a way that conventional scanners can detect. The vulnerability triggers when JavaScript processes untrusted data from sources like URL fragments, postMessage, or client-side storage and writes it to dangerous sinks without proper sanitization.
// Vulnerable code example
const urlParams = new URLSearchParams(window.location.search);
const searchTerm = urlParams.get('search');
document.getElementById('results').innerHTML = searchTerm; // Dangerous sink
Step-by-step guide explaining what this does and how to use it:
1. The code extracts the ‘search’ parameter from the URL query string
2. It directly injects this user-controlled data into innerHTML without validation
3. An attacker can craft a malicious
URL: `https://example.com/?search=<script>alert(1)</script>`
4. When victims visit this URL, the script executes in their browser context
5. This occurs entirely client-side – the server never sees the malicious payload
2. Manual DOM XSS Detection Methodology
Effective DOM XSS hunting requires systematic manual testing focused on identifying sources and sinks throughout the application’s JavaScript codebase.
Extract JavaScript endpoints from target waybackurls target.com | grep ".js$" | httpx -status-code | grep 200 Search for common source patterns in JS files curl -s https://target.com/app.js | grep -E "(location.|document.|window.|URLSearchParams|localStorage)"
Step-by-step guide explaining what this does and how to use it:
1. Use automated tools to discover all JavaScript files loaded by the application
2. Manually review each JavaScript file for dangerous source patterns: location.hash, location.search, document.referrer, window.name
3. Trace the data flow from these sources to dangerous sinks: innerHTML, outerHTML, document.write, eval, setTimeout with string
4. Test each potential vector by injecting payloads and monitoring execution
5. Use browser developer tools to set breakpoints and trace execution flow
3. Weaponizing DOM XSS with Proof-of-Concept Exploits
Moving from detection to exploitation requires crafting payloads that demonstrate real business impact beyond simple alert boxes.
// Advanced DOM XSS payload for data exfiltration
Step-by-step guide explaining what this does and how to use it:
1. Craft a payload that leverages the application’s own authentication context
2. Use fetch() API to make authenticated requests to sensitive endpoints
3. Extract response data and exfiltrate to attacker-controlled server
4. Encode exfiltrated data in base64 to handle special characters
5. Test the payload in authenticated session to demonstrate impact
6. Document the complete attack flow for your bug report
4. Bypassing Common DOM XSS Defenses
Modern applications implement various client-side protections that require creative bypass techniques.
[bash]
// Bypass basic filter example
// If application filters
