Dom Invader Assistant

DOM Invader Assistant

A skill for helping users leverage Burp Suite's DOM Invader tool to detect and exploit client-side vulnerabilities.

When to Use This Skill

Use this skill when:

• The user wants to test for DOM XSS vulnerabilities
• The user needs help enabling or configuring DOM Invader in Burp Suite
• The user is investigating prototype pollution or DOM clobbering issues
• The user needs guidance on canary injection techniques
• The user wants to test postMessage handlers
• The user is doing client-side security testing with Burp Suite

Quick Start

1. Enable DOM Invader: Open Burp's embedded browser (Proxy → Intercept → Open Browser), click the Burp Suite logo (top-right), toggle "Enable DOM Invader" ON, and reload the page.

2. Open DevTools: Press F12 or right-click → Inspect to access the DOM Invader panel.

3. Inject a Canary: Copy the canary value and inject it into parameters, forms, or web messages.

4. Monitor Sinks: Watch the DOM Invader panel for flagged sinks and their context.

Core Features

Canary Injection

The canary is a random marker string (e.g., xh9XKYlV) that DOM Invader tracks throughout the application.

Manual injection:

• Copy the canary and inject it into parameters, forms, WebSocket frames, or web messages
• Use "Inject URL params" or "Inject forms" buttons to automatically append the canary to every query parameter or form field
• Search for an empty canary to reveal all sinks regardless of exploitability (great for reconnaissance)

Custom canary (Burp 2024.12+):

• Access Canary settings via Burp logo → DOM Invader → 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 browser reload

Web Messages (postMessage)

The Messages sub-tab records every window.postMessage() call, showing origin, source, and data usage.

Modify & resend:

• Double-click a message, edit data, and press Send (Burp Repeater-like)

Auto-fuzz:

• Enable Postmessage interception → Auto-mutate in settings to let DOM Invader generate canary-based payloads and replay them to the handler

Field meanings:

• origin – whether the handler validates event.origin
• data – payload location. If unused, the sink is irrelevant
• source – iframe/window reference validation; often weaker than strict-origin checking

Prototype Pollution

Enable under Settings → Attack types → Prototype pollution.

Workflow:

1. Browse – DOM Invader flags pollution sources (__proto__, constructor, prototype) found in URL/query/hash or JSON web-messages
2. Test – click Test to open a PoC tab where Object.prototype.testproperty should exist:

   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

Advanced settings (cog icon):

• 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

DOM Clobbering

Toggle Attack types → DOM clobbering. DOM Invader monitors dynamically created elements whose id/name attributes collide with global variables or form objects (e.g., <input name="location"> → clobbers window.location). An entry is produced whenever user-controlled markup leads to variable replacement.

Settings Overview

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

Attack Types

• Prototype pollution (with per-technique settings)
• DOM clobbering

Misc

• Redirect prevention – block client-side redirects so the sink list isn't 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

Canary

• View / randomize / set custom canary; copy to clipboard. Changes require browser reload.

Best 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

Troubleshooting

DOM Invader panel not appearing:

• Verify it's enabled in the Burp logo menu
• Reload the page after enabling
• Check that DevTools is open

Canary not showing up in sinks:

• Try an empty canary search
• Check if the page is blocking the injection
• Verify the canary is actually being injected

Prototype pollution tests failing:

• Check if the app is using strict mode
• Try different pollution techniques
• Verify the gadget chain exists

DOM clobbering not detected:

• Check for dynamically created elements
• Verify id/name attributes are being set
• Ensure the clobbering is actually affecting global variables

References

• PortSwigger DOM Invader Documentation
• Enabling DOM Invader
• DOM XSS Testing
• Web Messages
• Prototype Pollution
• DOM Clobbering
• Canary Settings
• Misc Settings