DOM-based Cross-Site Scripting Attack in Depth

Last Updated : 21 Jun, 2021

In this article, we will be understanding one of the types of Cross-Site Scripting in-depth i.e DOM-based XSS. Let’s discuss it one by one as follows.

DOM-based Cross Site Scripting :

DOM XSS stands for Document Object Model-based Cross-site Scripting. DOM-based vulnerabilities occur in the content processing stage performed on the client, typically in client-side JavaScript.
DOM-based XSS works similar to reflected XSS one — attacker manipulates client’s browser environment (Document Object Model) and places payload into page content. The main difference is, that since the malicious payload is stored in the browser environment, it may be not sent on the server-side. This way all protection mechanisms related to traffic analysis will fail.
In reflective and stored Cross-site scripting attacks you can see the vulnerability malicious script in the response page but in DOM-based cross-site scripting, the HTML source code and the response of the attack will be the same, i.e. the malicious script cannot be found in the response from the web server.
In a DOM-based XSS attack, the malicious string is not parsed by the victim’s browser until the website’s legitimate JavaScript is executed. To perform a DOM-based XSS attack, you need to place data into a source so that it is propagated to a sink and causes the execution of arbitrary JavaScript code.

Breakdown of a DOM-based XSS attack :
The following is a breakdown of a DOM-based XSS attack as follows.

Attacker discovers the DOM-based XSS vulnerability
The hacker or attacker crafts a malicious script and sends the URL to the target(Email, social media, etc)
Victim clicks on the URL
Victims browser sends a request to the vulnerable site (note: the request does not contain the XSS malicious script)
The web server responds with the web page (note: this response does not contain the XSS malicious script)
Victims web browser renders the page, with the hackers or attackers XSS malicious script

Impact :

Steal another client’s cookies or sessions.
Modify another client’s cookies or sessions.
Steal another client’s submitted form information or some sensitive credentials.
Modify another client’s submitted form data or information by intercepting the request (before it reaches the server).

Note –
Submit a form to your application on the user’s behalf which modifies passwords or sensitive data on server or other application data.

Finding DOM-based Cross Site Scripting :

Most DOM XSS vulnerabilities can be found rapidly and efficiently using Burp Suite’s tool scanner or some other scripts which are available on GitHub.
To test for DOM-based cross-site scripting manually, you generally need to use a web browser with developer tools, such as Chrome or Firefox.
You need to work through each available source or input field in turn and test each one individually.

Understanding DOM-based Attack via Diagram:

DOM XSS Steps

Diagram Description –
From the above fig, “Consider diagram arrow numbers (Step 1 to Step 6) as steps” as follows.

Step-1: An attacker crafts the URL and sends it to a victim.
Step-2: The victim clicks on it and the request goes to the server.
Step-3: The server response contains the hard-coded JavaScript.
Step-4: The attacker’s URL is processed by hard-coded JavaScript, triggering his payload.
Step-5: The victim’s browser sends the cookies to the attacker.
Step-6: Attacker hijacks user’s session.

Example :
Example of a DOM-based XSS Attack as follows.

<HTML>
<TITLE>Hello!</TITLE>
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<BR>
Welcome To Our Website
…
</HTML>

Explanation –
Normally, this HTML page would be used for welcoming the user, e.g –

http://www.victim.site/hello.html?name=Gaurav

However, a request such as the one below would result in an XSS condition as follows.

http://www.victim.site/hello.html?name=alert(document.domain)

Remediation from DOM-based XSS:

Detecting DOM XSS is hard using purely server-side detection (i.e. HTTP requests), which is why providers like Acunetix leverages DeepScan to do it.
These malicious scripts or payloads are never sent to the web server due to being behind an HTML fragment (everything behind the # symbol).
As a result, the root issue is in the code (i.e. JavaScript) that is on the source page. This means that you should always sanitize or filter user input, irrespective of whether it is client-side
To remediate DOM-based XSS, data must not be dynamically written from any un-trusted source into the HTML document. Security controls must be in place if the functionality requires it.
It may involve a combination of JavaScript escaping, HTML encoding, and URL encoding.
Frameworks like AngularJS and React use templates that make the construction of ad-hoc HTML an explicit (and rare) action. This will boost your development team towards best practices, and make unsafe operations easier to detect.

Note –
The following source attributes should be avoided like URL, document URI, location, href, search, hash.

Suggest improvement

Same Site Scripting

Differences between WordPress and Weebly

Share your thoughts in the comments