Exploiting DOM-based XSS

Hello! Welcome to the final lesson in our module on Cross-Site Scripting.

In our previous lessons, you learned to exploit Reflected XSS (where the payload is in the request and immediately returned in the response) and Stored XSS (where the payload is saved by the server and served to future visitors). In both cases, the server plays a direct role in delivering the payload to the victim.

Today, we shift our focus entirely to the client side. Your learning outcome is to analyze client-side code to identify and exploit DOM-based XSS vulnerabilities. This type of XSS occurs when a web application's client-side scripts handle data from an untrusted source in an unsafe way. The server itself can be perfectly secure, yet the application can still be vulnerable. For a bug bounty hunter, mastering DOM XSS is critical as it's a frequent and often subtle bug class.

Let's begin.

1. Understanding the DOM and DOM-based XSS

At the heart of DOM XSS is the Document Object Model (DOM). The DOM is the browser's in-memory representation of an HTML document, structured as a tree of objects. JavaScript can interact with this tree to dynamically change the page's content, structure, and style.

DOM-based XSS happens when JavaScript takes data from an attacker-controllable location (a source) and passes it to a dangerous function that can execute scripts (a sink) without proper sanitization.

The key difference from other XSS types is that the payload is processed entirely on the client-side. The server may never even see the payload.

As the video explained, the vulnerable flow looks like this:

Attacker-controlled Source → Unsafe Processing in JavaScript → Dangerous Sink

2. Manual Analysis: Hunting for DOM XSS

Your Computer Science background and experience with JavaScript give you a significant advantage here. Hunting for DOM XSS is essentially a code review and debugging exercise performed within the browser. The process involves two main steps: finding potential sinks and tracing the data flow back to see if it originates from a controllable source.

Let's walk through this manual process.

To formalize this process, here is a textual guide from PortSwigger that you can use as a reference during your hunts.

The general workflow is:

1. Identify Sinks: Use your browser's dev tools to search across all JavaScript files for known dangerous sinks.
2. Trace Backwards: Once you find a sink, set a breakpoint in the debugger just before the sink is called. Refresh the page with some test input. When the breakpoint hits, inspect the variables being passed to the sink. Trace them backwards to see if they originate from a source you control (like location.hash, location.search, document.referrer, etc.).
3. Confirm Control: Manipulate the source (e.g., by changing the URL) and observe if your input reaches the sink.

function displayMessage() {
  var url = new URL(window.location.href);
  var message = url.searchParams.get("message");
  var container = document.getElementById("message-box");
  container.innerHTML = "Your message: " + message;
}

displayMessage();

3. Exploitation: Sinks, Context, and Payloads

Once you've confirmed a source-to-sink data flow, exploitation depends on the sink and the context it provides. Different sinks have different behaviors.

Real-World Examples from Bug Bounty Reports

Theory is great, but seeing how these vulnerabilities are found and reported in the wild is invaluable. Let's analyze some real bug bounty reports.

The GitLab report is a prime example of advanced bug hunting. The researcher didn't just find a source and a sink; they understood that the vulnerability was only triggered when the clipboard data had a specific MIME type. This level of detailed analysis is what separates top-tier hunters.

4. Automating Discovery with DOM Invader

Manually tracing JavaScript can be time-consuming, especially with large, minified codebases. Burp Suite Professional includes a powerful extension called DOM Invader that automates much of this process.

DOM Invader instruments the browser to find controllable sources, test them against known sinks, and even generate proof-of-concept exploits.

While tools like DOM Invader are powerful accelerators, remember that a strong manual methodology is irreplaceable. The tool helps you find potential issues quickly, but your ability to manually verify, understand the context, and craft a bypass for any filters is what will lead to a successful report.

Conclusion

You have now covered the three major types of Cross-Site Scripting. DOM-based XSS is a purely client-side vulnerability that requires a deep dive into an application's JavaScript code, making it a perfect challenge for your analytical skills.

Key Takeaways:

• DOM XSS is Client-Side: The vulnerability exists in the scripts running in the user's browser, independent of the server's security.
• It's All About Source-to-Sink: The core of the vulnerability is the flow of untrusted data from a source (e.g., location.hash) to a dangerous sink (e.g., innerHTML).
• Analysis is Code Review: Finding DOM XSS involves using browser developer tools to search for sinks and use the debugger to trace data flow back to a controllable source.
• Exploitation is Context-Dependent: The payload needed to achieve XSS depends entirely on the sink being used and the HTML surrounding it.
• Automation Helps, Manual Skill Wins: Tools like DOM Invader are excellent for identifying potential vulnerabilities, but manual verification and exploit crafting are essential skills.

Next Lesson Preview:
In the next lesson, we will move on to the next major vulnerability class in web applications: Server-Side Injection & File Inclusion Attacks. You will start by learning to identify and exploit OS command injection, a critical vulnerability that allows an attacker to execute arbitrary commands on the server's operating system.