Hello folks,
This blog focuses on how we can identify and exploit DOM-based Cross-site Scripting (XSS) vulnerabilities on websites. We will be practicing these vulnerabilities on the PortSwigger platform.
You can check out the Portswigger’s labs for DOM-based Cross-site Scripting vulnerability.
If you want to learn about Cross-site Scripting (XSS) and its types then you can check out our blog on Reflected and Stored XSS.
Let’s start and understand DOM-based XSS. The acronym “DOM” represents the Document Object Model. This model acts as a framework for organizing the structure of web pages, arranging elements like paragraphs or headings into a hierarchical structure where each element (tag) is treated as a node.
DOM-based XSS refers to a particular form of XSS attack where malicious code is executed by manipulating the DOM environment in the user’s browser. Unlike traditional XSS methods where harmful code is inserted directly into the HTML generated by the server, DOM-based XSS occurs after the page has loaded, without needing server-side involvement. Essentially, DOM-based XSS takes advantage of vulnerabilities in client-side scripts of web applications, allowing attackers to run unauthorized code within a victim’s browser, potentially leading to security breaches such as data theft or unauthorized access.
Let’s now proceed without any delay and begin the penetration testing process for DOM-based XSS on PortSwigger’s labs.
Lab 1- DOM XSS in document.write sink using source location.search
In the DOM, sink, and source are used in data flow. Source is a method that refers to the origin of an input. Here location.search is a source as it helps us to get the contents from the URL. Sink is a method where the input from the source will be directed or used. Here, document.write is a sink as it is used to write the input to a webpage.
In this lab, we will explore the method to identify a DOM XSS on a website. We can read the lab description and click on ‘Access The Lab’. This lab can be performed without Burp Suite as well.
Whenever we target XSS vulnerability, we must find an input parameter that simply includes our input string somewhere on the client side’s web page. On this website, we have a search functionality where we can check whether our value is getting reflected or not. Let’s provide any string in the search field and check the source code. We will find that the input is reflected in the source code. But remember, when we are targeting DOM-based vulnerabilities, we need to check whether our input is reflected in the Inspect Element or not.
We will find that on the inspect element, we found 2 reflections of the provided input which confirms the presence of DOM. Now, somehow we have to execute a malicious JavaScript alert function within the DOM. If we check the DOM, we will find that our input is enclosed within the img tag. So, we have to first close the img tag and then execute our malicious JS code. We can use the following JS code to do so:
“><script>alert(“CyberiumX”)</script>
As soon as we submit the above code, we will find that the alert function is executed. This is how we identify and exploit DOM XSS vulnerability. Hence the lab is solved.
Lab 2- DOM XSS in document.write sink using source location.search inside a select element
In this lab, we will explore how can we execute the malicious JS payload after closing the parent tags. We can read the lab description and click on ‘Access The Lab’. This lab requires the Burp Suite Community edition.
Whenever we target XSS vulnerability, we must find an input parameter that simply includes our input string somewhere on the client side’s web page. On this website, we have a product page where we can check each product’s stock availability by clicking on the ‘Check stock’ button. If we check this POST request on Burp Suite, we will find that there are two body parameters used (productId and storeId). If we supply any random string on these parameters, we will see that the values are not reflected anywhere on the website.
Now, let’s try to provide both of these parameters in the URL as a GET request and supply random characters. We will find that the value provided in the storeId parameter is included in the webpage. Also, if we check the inspect element we will find that our value is included in another <option> tag.
Now, if we check that our payload is enclosed in <option> and then in <select> tag. So, we have to close these tags to execute our malicious JS code. We can write the following payload in the storeId parameter to generate an alert on the webpage.
</option></select><script>alert(“CyberiumX”)</script>
As soon as we submit the above code, we will find that the alert function is executed. This is how we identify and exploit DOM-based XSS vulnerability by closing the parent tags. Hence the lab is solved.
Lab 3- DOM XSS in innerHTML sink using source location.search
In this scenario we will understand if the target web application is using innerHTML as a sink then we cannot use <script> or <svg> XSS payloads to confirm the vulnerability. We have to either use <iframe> or <img> elements to exploit the vulnerability in DOM. Let’s see this in practice.
On this website, we have a search functionality where we can check whether our value is getting reflected or not. Let’s provide any string in the search field and check the source code. We will find that the input is not reflected anywhere in the source code. For DOM-based XSS, we have to check the Inspect Element and there we found the reflection of our provided input.
We can provide any of the following payloads to exploit the vulnerability:
</span><img src=a onerror=alert(“CyberiumX”)>
Or
<img src=a onerror=alert(“CyberiumX”)>
Once we submit the value, we will find that the malicious XSS payload is executed.
This is how we identify and exploit DOM-based XSS vulnerability within the innerHTML sink. Hence the lab is solved.
In this blog, we covered the basics of DOM-based XSS vulnerability and learned about how to identify and exploit the vulnerability. In the upcoming blog, we will explore the same in third-party dependencies and with reflected and stored XSS.
You can check out our other web application penetration testing blogs on our website.
Happy Pentesting!
Team CyberiumX