Vulnerability Type: DOM-based Cross-Site Scripting (XSS)
Attack Vector
The vulnerable application dynamically injects user-controlled input from `location.search` (URL parameters) into the DOM using the `innerHTML` property, without proper sanitization. This allows an attacker to inject arbitrary HTML/JavaScript, leading to script execution when the payload is rendered.
Exploitation Steps
- Identify the Sink and Source:
- The search query (e.g., `?search=test`) is reflected in the page’s DOM via `innerHTML`.
- Inspect the element to observe the input embedded unsafely within a DOM node.
- Craft Malicious Payload:
- Inject an `<img>` tag with an invalid `src` and an `onerror` handler: <img src=1 onerror=alert(1)>
- The invalid `src` triggers the `onerror` event, executing the embedded JavaScript.
- Trigger the Exploit:
- Enter the payload into the search box and click “Search”.
- The resulting URL will look like: https://vulnerable-site.com/?search=<img src=1 onerror=alert(1)>
- The `innerHTML` property sinks the payload into the DOM, rendering the malicious `<img>` tag.
- Confirmation:
- The browser attempts to load the invalid image (`src=1`), fails, and fires the `onerror` event, executing `alert(1)`.
Mitigation Strategies
- Avoid `innerHTML` for Untrusted Input:Use safer alternatives like `textContent` or `innerText` for dynamic content insertion.
- Input Sanitization: Sanitize URL parameters before embedding them in the DOM (e.g., strip or encode HTML tags).
- Content Security Policy (CSP): Implement CSP to restrict inline scripts and unsafe `eval()` functions.
- Use Trusted Libraries: Leverage libraries like DOMPurify to sanitize HTML before injection.
Key Takeaway
This lab demonstrates how unsafe use of `innerHTML` with user-controlled input can lead to DOM XSS. Unlike server-side XSS, this vulnerability arises entirely client-side, making it critical to sanitize inputs and avoid risky DOM manipulation methods.
