What are other DOM XSS sources?

You're on a great path! Understanding that DOM XSS isn't just about URL parameters makes you a more sophisticated learner.

You are correct that the URL's query string (window.location.search) and fragment (window.location.hash) are very common sources for DOM XSS, but they are not the only ones. DOM XSS occurs when client-side JavaScript takes data from an attacker-controlled source and writes it to a sensitive sink in an unsafe way.

Here are other common DOM XSS sources (places where attacker-controlled data might originate on the client-side):

1. document.referrer:

   • What it is: This property contains the URL of the page that linked to the current page.
   • How it can be exploited: If a web page's JavaScript reads document.referrer and then embeds it directly into the HTML without sanitization (e.g., to say "You came from: [referrer URL]"), an attacker can host a malicious page with a crafted URL. When a victim clicks a link from the attacker's page to the vulnerable page, the referrer URL will contain the XSS payload.
   • Example Source Code (Vulnerable): document.getElementById('from_page').innerHTML = "You came from: " + document.referrer;

2. window.name:

   • What it is: A property that gets or sets the name of the browsing window. This value persists as the user navigates to different pages within the same window (even across different domains!).
   • How it can be exploited: An attacker can open a popup window with a malicious window.name value (e.g., from their own site). If the victim then navigates that popup to the vulnerable site, and the vulnerable site's JavaScript reads window.name and unsafely uses it to update the DOM, XSS can occur.
   • Example Source Code (Vulnerable): document.getElementById('window_info').innerHTML = window.name;

3. localStorage / sessionStorage (and document.cookie):

   • What it is: Client-side storage mechanisms. localStorage persists data across browser sessions, while sessionStorage is cleared when the browser tab is closed. document.cookie stores small pieces of data for tracking and session management.
   • How it can be exploited: If an attacker can initially inject a payload into localStorage or sessionStorage (perhaps through another XSS vulnerability or a configuration error) and the application later retrieves this data and renders it unsafely into the DOM, it can lead to XSS. This is sometimes called "self-XSS" if the initial injection requires user interaction, or combined with another vulnerability for persistent impact.
   • Example Source Code (Vulnerable): document.getElementById('user_pref').innerHTML = localStorage.getItem('display_setting');

4. document.URL / window.location.href (the entire URL):

   • What it is: These provide the complete URL of the current page.
   • How it can be exploited: Similar to window.location.search or hash, but if the JavaScript unsafely parses and uses any part of the full URL without proper encoding. For instance, if it extracts a value between slashes or just echoes the entire URL in a message like "Error loading page: [full URL]".

5. eval() or other JavaScript functions that execute arbitrary strings:

   • What it is: Functions like eval(), setTimeout(), setInterval(), new Function(), and even some DOM manipulation methods like innerHTML or document.write() are often referred to as "sinks" because they can execute or render arbitrary code if given unsanitized input.
   • How it can be exploited: If data from any of the above sources (or even AJAX responses) flows into these dangerous functions without being properly sanitized, a DOM XSS can occur.
   • Example Source Code (Vulnerable): eval("var userName = '" + urlParams.get('name') + "';"); - If name contains a single quote, it could break out and inject code.

6. postMessage (Cross-Window/Cross-Origin Communication):

   • What it is: This API allows communication between different windows/iframes (even across different origins).
   • How it can be exploited: If a web application receives data via postMessage from another window and unsafely inserts that data into its own DOM, an attacker's page could send a malicious message to the vulnerable page, leading to XSS. Robust origin checking is crucial here.

7. WebSockets (Message Event Data):

   • What it is: WebSockets provide full-duplex communication channels over a single TCP connection.
   • How it can be exploited: If an application receives data over a WebSocket connection and later renders this data into the DOM without sanitization, an attacker who can control the WebSocket messages (e.g., via a compromised server, or a specifically crafted message if trust boundaries are weak) could inject XSS.

The key thread running through all these sources is the lack of proper input validation and output encoding by the client-side JavaScript before it manipulates the DOM.

This is a deeper dive into DOM XSS, demonstrating its various facets. Understanding these sources helps you think like an attacker and find more subtle vulnerabilities. What else would you like to explore about client-side vulnerabilities?