Add content from: Research Update: Enhanced src/pentesting-web/xss-cross-site-...

This commit is contained in:
HackTricks News Bot 2025-07-31 01:44:28 +00:00
parent 99406ac909
commit 57208abfd4

View File

@ -4,80 +4,123 @@
## DOM Invader
DOM Invader is a browser tool installed in Burp's inbuilt browser. It assists in **detecting DOM XSS vulnerabilities** using various sources and sinks, including web messages and prototype pollution. The tool is preinstalled as an extension.
DOM Invader is a browser tool installed in **Burp Suite's built-in Chromium browser**. It assists in **detecting DOM XSS and other client-side vulnerabilities** (prototype pollution, DOM clobbering, etc.) by automatically **instrumenting JavaScript sources and sinks**. The extension ships with Burp and only needs to be enabled.
DOM Invader integrates a tab within the browser's DevTools panel enabling the following:
DOM Invader adds a tab to the browsers DevTools panel that lets you:
1. **Identification of controllable sinks** on a webpage for DOM XSS testing, providing context and sanitization details.
2. **Logging, editing, and resending web messages** sent via the `postMessage()` method for DOM XSS testing. DOM Invader can also auto-detect vulnerabilities using specially crafted web messages.
3. Detection of **client-side prototype pollution** sources and scanning of controllable gadgets sent to risky sinks.
4. Identification of **DOM clobbering vulnerabilities**.
1. **Identify controllable sinks** in real time, including context (attribute, HTML, URL, JS) and applied sanitization.
2. **Log, edit and resend `postMessage()` web-messages**, or let the extension mutate them automatically.
3. **Detect client-side prototype-pollution sources and scan for gadget→sink chains**, generating PoCs on-the-fly.
4. **Find DOM clobbering vectors** (e.g. `id` / `name` collisions that overwrite global variables).
5. **Fine-tune behaviour** via a rich Settings UI (custom canary, auto-injection, redirect blocking, source/sink lists, etc.).
### Enable It
---
In the Burp's builtin browser go to the **Burp extension** and enable it:
### 1. Enable it
<figure><img src="../../images/image (1129).png" alt=""><figcaption></figcaption></figure>
1. Open **Proxy ➜ Intercept ➜ Open Browser** (Burps embedded browser).
2. Click the **Burp Suite** logo (top-right). If its hidden, click the jigsaw-piece first.
3. In **DOM Invader** tab, toggle **Enable DOM Invader** ON and press **Reload**.
4. Open DevTools ( `F12` / Right-click ➜ Inspect ) and dock it. A new **DOM Invader** panel appears.
Noe refresh the page and in the **Dev Tools** you will find the **DOM Invader tab:**
> Burp remembers the state per profile. Disable it under *Settings ➜ Tools ➜ Burps browser ➜ Store settings...* if required.
<figure><img src="../../images/image (695).png" alt=""><figcaption></figcaption></figure>
### 2. Inject a Canary
### Inject a Canary
A **canary** is a random marker string (e.g. `xh9XKYlV`) that DOM Invader tracks. You can:
In the previous image you can see a **random group of chars, that is the Canary**. You should now start **injecting** it in different parts of the web (params, forms, url...) and each time click search it. DOM Invader will check if the **canary ended in any interesting sink** that could be exploited.
* **Copy** it and manually inject it in parameters, forms, Web-Socket frames, web-messages, etc.
* Use **Inject URL params / Inject forms** buttons to open a new tab where the canary is appended to every query key/value or form field automatically.
* Search for an **empty canary** to reveal all sinks regardless of exploitability (great for reconnaissance).
Moreover, the options **Inject URL params** and Inject forms will automatically open a **new tab** **injecting** the **canary** in every **URL** param and **form** it finds.
#### Custom canary (2025+)
### Inject an empty Canary
Burp 2024.12 introduced **Canary settings** (Burp-logo ➜ DOM Invader ➜ Canary). You can:
If you just want to find potential sinks the page might have, even if they aren't exploitable, you can **search for an empty canary**.
* **Randomize** or set a **custom string** (helpful for multi-tab testing or when the default value appears naturally on the page).
* **Copy** the value to clipboard.
* Changes require **Reload**.
### Post Messages
---
DOM Invader allows testing for DOM XSS using web messages with features such as:
### 3. Web-messages (`postMessage`)
1. **Logging web messages** sent via `postMessage()`, akin to Burp Proxy's HTTP request/response history logging.
2. **Modification** and **reissue** of web messages to manually test for DOM XSS, similar to Burp Repeater's function.
3. **Automatic alteration** and sending of web messages for probing DOM XSS.
The **Messages** sub-tab records every `window.postMessage()` call, showing `origin`, `source`, and `data` usage.
#### Message details
**Modify & resend**: double-click a message, edit `data`, and press **Send** (Burp Repeater-like).
Detailed information can be viewed about each message by clicking on it, which includes whether the client-side JavaScript accesses the `origin`, `data`, or `source` properties of the message.
**Auto-fuzz**: enable **Postmessage interception ➜ Auto-mutate** in settings to let DOM Invader generate canary-based payloads and replay them to the handler.
- **`origin`** : If the **origin information of the message is not check**, you may be able to send cross-origin messages to the event handler **from an arbitrary external domain**. But if it's checked it still could be insecure.
- **`data`**: This is where the payload is sent. If this data is not used, the sink is useless.
- **`source`**: Evaluates if the source property, usually referencing an iframe, is validated instead of the origin. Even if this is checked, it doesn't assure the validation can't be bypassed.
Field meaning recap:
#### Reply a message
* **origin** whether the handler validates `event.origin`.
* **data** payload location. If unused, the sink is irrelevant.
* **source** iframe / window reference validation; often weaker than strictorigin checking.
1. From the **Messages** view, click on any message to open the message details dialog.
2. Edit the **Data** field as required.
3. Click **Send**.
---
### Prototype Pollution
### 4. Prototype Pollution
DOM Invader can also search for **Prototype Pollution vulnerabilities**. First, you need to enable it:
Enable under **Settings ➜ Attack types ➜ Prototype pollution**.
<figure><img src="../../images/image (1026).png" alt=""><figcaption></figcaption></figure>
Workflow:
Then, it will **search for sources** that enable you to add arbitrary properties to the **`Object.prototype`**.
1. **Browse** DOM Invader flags pollution **sources** (`__proto__`, `constructor`, `prototype`) found in URL/query/hash or JSON web-messages.
2. **Test** clicks *Test* to open a PoC tab where `Object.prototype.testproperty` should exist:
If anything is found a **Test** button will appear to **test the found source**. Click on it, a new tab will appear, create an object in the console and check if the `testproperty` exists:
```javascript
let obj = {};
console.log(obj.testproperty); // ➜ 'DOM_INVADER_PP_POC'
```
3. **Scan for gadgets** DOM Invader bruteforces property names and tracks whether any end up in dangerous sinks (e.g. `innerHTML`).
4. **Exploit** when a gadget-sink chain is found an *Exploit* button appears that chains source + gadget + sink to trigger alert.
```javascript
let b = {}
b.testproperty
```
Advanced settings (cog icon):
Once you found a source you can **scan for a gadget**:
* **Remove CSP / X-Frame-Options** to keep iframes workable during gadget scanning.
* **Scan techniques in separate frames** to avoid `__proto__` vs `constructor` interference.
* **Disable techniques** individually for fragile apps.
1. A new tab is opened by DOM Invader when the **Scan for gadgets** button, which can be found next to any identified prototype pollution source in the **DOM** view, is clicked. The scanning for suitable gadgets then begins.
2. Meanwhile, in the same tab, the **DOM Invader** tab should be opened in the DevTools panel. After the scan completes, any sinks accessible via the identified gadgets are displayed in the **DOM** view. For instance, a gadget property named `html` being passed to the `innerHTML` sink is shown in the example below.
---
## DOM clobbering
### 5. DOM Clobbering
In the previous image it's possible to see that DOM clobbering scan can be turned on. Once done, **DOM Invader will start searching for DOM clobbering vulnerabilities**.
Toggle **Attack types ➜ DOM clobbering**. DOM Invader monitors dynamically created elements whose `id`/`name` attributes collide with global variables or form objects (`<input name="location">` → clobbers `window.location`). An entry is produced whenever user-controlled markup leads to variable replacement.
---
## 6. Settings Overview (2025)
DOM Invader is now split into **Main / Attack Types / Misc / Canary** categories.
1. **Main**
* **Enable DOM Invader** global switch.
* **Postmessage interception** turn on/off message logging; sub-toggles for auto-mutation.
* **Custom Sources/Sinks** *cog icon* ➜ enable/disable specific sinks (e.g. `eval`, `setAttribute`) that may break the app.
2. **Attack Types**
* **Prototype pollution** (with per-technique settings).
* **DOM clobbering**.
3. **Misc**
* **Redirect prevention** block client-side redirects so the sink list isnt lost.
* **Breakpoint before redirect** pause JS just before redirect for call-stack inspection.
* **Inject canary into all sources** auto-inject canary everywhere; configurable source/parameter allow-list.
4. **Canary**
* View / randomize / set custom canary; copy to clipboard. Changes require browser reload.
---
### 7. Tips & Good Practices
* **Use distinct canary** avoid common strings like `test`, otherwise false-positives occur.
* **Disable heavy sinks** (`eval`, `innerHTML`) temporarily if they break page functionality during navigation.
* **Combine with Burp Repeater & Proxy** replicate the browser request/response that produced a vulnerable state and craft final exploit URLs.
* **Remember frame scope** sources/sinks are displayed per browsing context; vulnerabilities inside iframes might need manual focus.
* **Export evidence** right-click the DOM Invader panel ➜ *Save screenshot* to include in reports.
---
## References
@ -87,8 +130,7 @@ In the previous image it's possible to see that DOM clobbering scan can be turne
- [https://portswigger.net/burp/documentation/desktop/tools/dom-invader/web-messages](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/web-messages)
- [https://portswigger.net/burp/documentation/desktop/tools/dom-invader/prototype-pollution](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/prototype-pollution)
- [https://portswigger.net/burp/documentation/desktop/tools/dom-invader/dom-clobbering](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/dom-clobbering)
- [https://portswigger.net/burp/documentation/desktop/tools/dom-invader/settings/canary](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/settings/canary)
- [https://portswigger.net/burp/documentation/desktop/tools/dom-invader/settings/misc](https://portswigger.net/burp/documentation/desktop/tools/dom-invader/settings/misc)
{{#include ../../banners/hacktricks-training.md}}