DOM XSS in jQuery selector sink using a hashchange event

DOM-based Cross-Site Scripting (DOM XSS) continues to be one of the more subtle yet impactful vulnerabilities in modern web applications. Unlike traditional XSS, which involves server-side injection, DOM XSS arises entirely within the browser when client-side JavaScript mishandles untrusted data. A particularly interesting variant appears when user-controlled input from the URL fragment (location.hash) is passed into a jQuery selector and processed dynamically through a hashchange event. This combination creates a powerful and often overlooked attack surface.

In many web applications, developers use the URL fragment identifier (the portion after #) to control client-side behavior such as navigation, filtering, or tab switching. For example, a page might update its content based on the current hash value, allowing users to navigate without triggering a full page reload. To achieve this, developers often bind a function to the hashchange event, which fires whenever the fragment identifier changes. Within this handler, it is common to retrieve the hash value and pass it directly into a jQuery selector, as seen in patterns like $(location.hash).

At first glance, this may seem harmless. However, the issue lies in how jQuery processes selector strings. jQuery uses a selector engine (commonly known as Sizzle) that parses the input string to determine which elements to match in the DOM. If user-controlled input is passed directly into this parser without validation, it opens the door to selector injection. In certain contexts, this can lead to DOM XSS, especially if the resulting selection influences DOM manipulation or triggers unintended behavior.

Consider a scenario where the application expects a simple ID selector such as #section1. Instead, an attacker supplies a crafted payload in the URL fragment. Because the hash is attacker-controlled, they can manipulate it to break out of the intended selector context and introduce additional logic. For instance, payloads that attempt to close the selector and append malicious constructs—such as #test')<img src=x onerror=alert(1)>—aim to inject HTML elements that can execute JavaScript via event handlers like onerror. While not all such payloads succeed directly due to how jQuery distinguishes between selectors and HTML, they illustrate the attacker’s goal: to escape the intended parsing context.

A more nuanced payload involves abusing advanced selector features such as :has(). For example, a fragment like #Black Masket Dealings')]:has(img[src=x onerror=alert(1)]) attempts to manipulate the selector engine into evaluating a condition that includes an image element with a malicious event handler. These payloads rely heavily on how the application processes the selector’s output. If the selected elements are later inserted into the DOM or otherwise manipulated in a way that causes embedded HTML to be interpreted, execution can occur indirectly.

The real exploitation power in this lab, however, comes from combining the selector sink with the hashchange event. Because the hash can be updated dynamically without reloading the page, attackers can trigger the vulnerable code multiple times and in controlled ways. One effective technique involves using an <iframe> to manipulate the hash after the page has loaded. For example, an attacker-controlled iframe can initially load the target page with a benign hash, then append a malicious payload to the fragment using JavaScript in the onload event. This updated hash triggers the hashchange handler, causing the application to process the new, malicious input.

This approach works because it introduces a second stage of execution. The initial page load may not trigger the vulnerability, but the subsequent hash update does. By carefully crafting the payload and timing its injection, attackers can bypass simplistic defenses or assumptions about how input is handled. It also demonstrates that the selector itself is not always the final execution point; rather, it is part of a chain that leads to DOM manipulation where execution ultimately occurs.

The root cause of this vulnerability is the unsafe use of user-controlled input in a context that expects structured data. Developers often assume that hash values will remain simple and predictable, but in reality, they are just as untrusted as query parameters. Passing them directly into jQuery selectors without sanitization effectively hands control of the selector engine to the attacker.

Mitigation requires a shift in how input is handled. Instead of passing raw hash values into $(), developers should extract only the necessary portion (such as an element ID) and validate it against a strict pattern or allowlist. Native DOM APIs like document.getElementById are safer alternatives when dealing with simple selectors, as they do not parse complex selector syntax. Additionally, avoiding dynamic selector construction altogether can significantly reduce risk.

In conclusion, DOM XSS via jQuery selector sinks highlights the importance of understanding how client-side libraries interpret input. The combination of location.hash, dynamic event handling through hashchange, and powerful selector parsing creates a non-obvious but exploitable pathway. For security practitioners, recognizing these patterns is essential, while for developers, adopting safer input handling practices is key to preventing such vulnerabilities.