Enable DOM invader.
DOM Invader can be found in burp’s build in browser, let’s open it.
Open burp’s build-in chrome browser.
Attached burp extension to browser.
Toggle on DOM invader, change the canary name to anything, i changed mine to “burpdomxss”, after change name click on “update canary”, then click on “reload” to apply the changes.
LAB 1: Inject canary into URL
https://portswigger-labs.net/dom-invader/testcases/augmented-dom-eval/
Initial page looks like this:
Right click, inspect, navigate to “DOM invader” tab.
From the page, click the “test” link, observe the changes in the URL and DOM invader tab.
Noted that our canary “burpdomxss” is injected into the URL, this is the same feature as the button “inject URL params”.
Noted that our canary is being used in eval() sink.
Noted that we have an “exploit” button under the “options”.
Click on “exploit” button from DOM invader, we got DOM-based XSS.
LAB 2: Inject canary into forms
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink
Initial page looks like this:
Click on “inject forms” to inject canary into forms:
Noted that our canary has been injected to the form, with some strings added to the back.
Let’s click on the “search” button to send our canary over and see the result.
Noted that the payload is also send via URL, which means we could modify our payload via URL.
Let’s try to modify the payload via URL and attempt to execute alert() function.
Did not work, noticed from the DOM invader we could see our payload in the server side, let’s analyze it:
- <img src=”xxx” onload=alert(1)”>
- Noted that there’s an extra double quote (“) after our alert() function, now we know what went wrong let’s complete the payload with x=” to close the trailing double quote.
Hit enter via the URL and attempt to trigger the XSS.
LAB 3: Auto fire event and redirection prevention
https://portswigger-labs.net/dom-invader/testcases/augmented-dom-click-location-replace/
Click on “test”, our canary is not being used in any source or sink.
Let’s turn on “auto fire events” and “redirection prevention” and attempt again.
If “auto fire events” is set to ON, this will automatically click on links for us and find the key events for us.
If “redirection prevention” is set to ON, this will stop the page from redirecting to a different URL, which could prevent us from finding the vulnerability.
After reload, we noted that there’s a sink and an exploit button.
Let’s try the exploit button, and we got XSS.
LAB 4: DOM XSS via web messages
Turn on “postmessage interception”, reload to apply changes.
Noted from Messages tab (bottom left) that there isn’t any web messages.
Let’s try to turn on “generate automated messages”, this time we noted some postmessages.
One of them is flagging red, showing it has high severity.
Let’s click on that high severity message to analyze it. Noted from the title and description that this is highly vulnerable.
Let’s attempt to Replay the Message, ie, we modify the data to XSS payload, and send it again.
It worked, we got XSS.
Conclusion
DOM invader is a powerful tool that will be useful for your XSS journey, its always good to analyze with it whenever you feel like there’s an DOM-based XSS.
