DOM Invader – Speeding up DOM-based XSS findings

Written By: Indrajeet Bhuyan

Cross-site scripting or XSS is a popular web application attack. It has found its place in OWASP 2013, OWASP 2017, and even in the latest OWASP 2021 (but with a name change). According to Hackerone’s 2021 report, the most common flaw which is discovered in their platform is cross-site scripting. 

Here in this article, we will talk about a very useful chrome extension provided by burp suite which makes finding DOM-based XSS very fast and easy. But before that let me give you a quick introduction to cross-site scripting. 

Cross-site scripting is a client-side attack. Here the attacker tries to execute malicious scripts in the web browser of the victim. It allows an attacker to carry out any actions that the user can perform, and to access any of the user’s data. 

There are 3 types of cross-site scripting: 

1. Reflected XSS – Here the code comes from the current Request and is not stored 

2. Stored XSS – Here the XSS code is stored in the database and comes each time someone visits the page (High impact) 

3. DOM-based XSS – Occurs when a web application writes data to the Document Object Model without proper sanitization. 

Today our main topic of discussion is the 3^rd type of XSS which is – DOM-based XSS. 

DOM is a convention that is used to represent and work with objects in HTML documents. All HTML documents have an associated DOM that consists of objects. DOM-based XSS arises when the web page takes data from an attacker-controllable source. For example – the URL passes it to a sink that supports dynamic code execution, and it executes the malicious code entered by the attacker. 

Here is an example of DOM XSS in document.write sink using source as location.search 

Many pentesters and bug bounty hunters don’t usually go for DOM-based XSS as identifying and exploiting DOM-based XSS involves a long hour of manual steps, going through complex JavaScript, and understanding how data is being taken and executed is a difficult task altogether.  

Let me introduce to you DOM Invader. A tool that will make finding DOM-based XSS very fast and easy. DOM-invader comes preinstalled as an extension in Burp suite’s browser. 

Open Burp suite and click on the proxy tab. Now in the proxy tab click on the Open browser tab 

Once the browser opens click on the pin to add the extension 

After adding the extension click on the icon and you can see two sub extensions. Click on DOM invader. 

When you click on the DOM invader you can see the color of the extension changing to blue. Now to begin you need to click on the enable button 

Now you need to update the canary with a keyword you like. For example, here I have added ‘secpro’ as a canary. 

Now click on inspect elements and you can see a new tab called DOM invader. 

Now as everything is set up let’s try out a DOM-based XSS demo and see how this extension can help us find the cross-site scripting. 

For the demo, I’m using this vulnerable link from Port swigger lab – http://portswigger-labs.net/dom-invader/testcases/augmented-dom-document-write/ 

Now click on test. 

Here let me add ‘secpro’ as I have used ‘secpro’ as the canary. 

Now after loading the page with the ‘secpro’ canary if we see the extension icon we can see that it shows us 1. 

This indicates that the extension has found a sink where the canary is returned. Now to check more we need to click on inspect element and then click on DOM-invader. 

This helps us to track back easily. Now, this extension helps us to stack trace in the dev tools console so that we can find where the canary is getting executed. Click on the stack trace link. 

Clicking on the stack trace link will open up the console. Now click on the last line link to get the exact location of the XSS execution. 

As you can see, we got the location of the execution. Now you can enter your payload and execute cross-site scripting. 

Here are some of the interesting DOM Invader settings which will make DOM XSS findings much easier for you. 

1. Message filtering by stack trace: 

As some websites show large numbers of messages that make testing difficult, this setting can help compare the stack trace of each entry and hides any entries that point to the same location in the code as an existing entry 

2. Redirection prevention:  

Sometimes our actions lead to DOM-based redirection to another page. This can create a problem in testing for DOM-based XSS as the view will be cleared and updated with the new source and sink of the new page. If you enable this setting, the DOM invader will stop the page from redirecting and help you stay on the same page so that you can test easily.