DE

DOM-Based Cross-Site Scripting Vulnerability – Testing & Prevention

In this article:

While Document Object Model (DOM) offers a powerful and flexible approach to modifying elements of a document, it can also be used as an attack vector. This article explores the basics, standard attack techniques, and best practices on how organizations can prevent DOM-based XSS attacks.



What is DOM?

The Document Object Model (DOM) is a programming interface that defines how to create, modify or erase elements in an HTML or XML document. DOM provides a standard API for the dynamic modification of the content, style, and structure of web page documents. A DOM model represents each element as a node within a tree-like system, enabling easier programmatic access and management of the elements.

By allowing the manipulation of documents, a DOM model enables object-oriented web page representation. This way, programming languages like JavaScript can modify and build dynamic web pages. DOM is platform and language-neutral to be used concurrently by multiple applications and environments.

DOM-based XSS Attack visualized - Crashtest Security

Cross-Site Scripting Explained

Cross-Site Scripting (XSS) is a security vulnerability that allows adversaries to execute malicious code on a victim’s web browser by circumventing the same-origin policy. A successful XSS attack allows the hacker to masquerade as the victim, with permission to access data and perform actions like a legitimate user. If the victim is a user with privileged access, the adversary may gain complete control of the application server, exposing it to further attacks. 

If a website is vulnerable to XSS, the attacker manipulates client-side scripts to present users with tampered JavaScript. The client-side code then executes this malicious JavaScript within the browser, allowing the adversary to intercept the interactions between the user and the web/application server.

Websites that do not validate user input before using them in their outputs are typically susceptible to XSS attacks. While various frameworks (such as ActiveX, Flash, CSS, and VBScript) are sensitive to XSS, dynamic websites commonly notice the attack since such sites mostly rely on JavaScript. 

XSS attacks are of three types:

  • Reflected XSS
  • Stored XSS
  • DOM-based XSS

What is DOM-based XSS?

DOM-based XSS is a cross-site scripting vulnerability that enables attackers to inject a malicious payload into a web page by manipulating the client’s browser environment. Since these attacks rely on the Document Object Model, they are orchestrated on the client-side after loading the page. In such attacks, the HTML source code and the response to the attack remain unchanged, so the malicious input is not included in the server response. Since the malicious payload is stored within the client’s browser environment, the attack cannot be detected using traditional traffic analysis tools.

DOM-based XSS attacks can only be seen by checking the document object model and client-side scripts at runtime.

Fundamentally, attackers perform DOM-based Cross-site scripting attacks on applications with an executable path for data to travel from a source to a sink. Sources are JavaScript properties that can act as the location of malicious input. These include document.URL, document.referrer, location.search, and location.hash among others. A sink is a location or function that executes the malicious function in an HTML rendering. Example of sinks include: eval, setTimeout, setInterval and element.innerHTML among others.

How to Prevent DOM XSS and its Importance in Security

The DOM-based XSS vulnerability enables adversaries to steal/modify legitimate users’ cookies or sessions to access sensitive data/functions. In the following section, we explore strategies to prevent DOM XSS-based attacks.

DOM XSS Attack Prevention

Some strategies to prevent DOM-based XSS include:

Using JavaScript Frameworks

JavaScript frameworks such as React and AngularJS are built with security best practices that eliminate ad-hoc HTML construction, making it harder for developers to include loopholes that allow adversaries to embed malicious user input into web Document Object models. 

In AngularJS, input is made safe by writing dynamic curly braces, escaping automatically. 

div>{{dynamicContent}}</div>

Binding content in ReactJS within curly braces also enables automatic escaping:

render() {
  return <div>{dynamicContent}</div>
}

Avoid the use of URI fragments.

The Universal Resource Indicator (URI) is an internal page reference mainly used to maintain the state of a JavaScript page after a user refreshes the website. The URI is a string of characters beginning with a hash appearing at the URL end to refer to a section within the page. URIs act as DOM-based XSS attack surfaces since they enable the dynamic loading and modification of content while not interacting directly with the server-side. The attacker can embed malicious scripts within URIs and trick the user into executing them.

To prevent such attacks, developers should avoid the use of URIs whenever possible. In an event where a URI is necessary, escaping dynamic content within the fragment is recommended.

Enforce a Content Security Policy (CSP).

Most modern browsers support the Content Security Policy – a security mechanism explicitly built to provide an additional layer of protection against attacks such as injection, clickjacking, and cross-site scripting vulnerability attacks. Configuring the HTTP Content Security Policy response header offers web developers control over resource access for each user entity. Developers can also specify valid script endpoints and server origins, preventing the execution of malicious user-supplied payloads.

Use an automated DOM XSS vulnerability scanner.

Development teams should leverage an automated scanner to test applications at runtime for DOM-XSS vulnerabilities continuously. Tools such as the Crashtest Security Suite scans JavaScript, APIs, and web applications with zero false positives and negatives, eliminating DOM-XSS security blind spots. 

Why is Preventing DOM XSS Important for your Business?

While DOM-based XSS is a client-side injection vulnerability, the malicious payloads are executed by code originating from the server. It is, therefore, the application developers’ responsibility to implement code-level protection against DOM-based XSS attacks. 

DOM-based XSS Examples

Some examples of DOM-based XSS attacks include:

1. Attack based on vulnerable content

Assume an HTML webpage with the following content:

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

This page is typically used as a landing page for account owners, e.g., http://www.vulnerable.site/welcome.html?name=Joe

In such instances, attackers can exploit the DOM to modify the query string such that it ends up with XSS, e.g.:

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

2. Attacks based on vulnerable user forms

Let us assume a code that lets the user select a time zone:

<select><script>

document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");

document.write("<OPTION value=2>CET</OPTION>");

</script></select>

In this case, the HTTP request http://www.some.site/page.html?default=CST  will invoke the page on the client browser.

Attackers can launch a DOM-based XSS attack by sending a malicious URL through a script as below:

http://www.example.site/page.html?default=<script>alert(document.cookie)</script>

Clicking this link sends a request to the www.example.site page, creating a DOM object for the page such that document.location URL parameter contains the string:

http://www.example.site/page.html?default=<script>alert(document.cookie)</script>

Any browser that renders this page executes the (alert(document.cookie)) malicious script.

FAQs

DOM XSS vs. Reflected XSS: What is the difference?

While DOM-based XSS shares a few similarities with traditional Reflected XSS, there are a few fundamental differences in technique and implementation.

  • Reflected XSS aims to embed client-side data to the server-side code in HTML documents, while in DOM-based XSS, the malicious payloads are referenced and executed on the client-side (browser) environment.
  • Reflected XSS can only target dynamic web pages, while DOM-based XSS targets static and dynamic web pages.
  • DOM-based attacks largely remain undetected if the adversary avoids server-side identification techniques, while traditional Reflected XSS attacks are easily detected using intrusion detection systems and logs.

What is the prevalence of DOM-based vulnerabilities?

DOM-based XSS vulnerabilities are uncommon and can only be found in about 1.2% of web applications. As such vulnerabilities are hard to uncover through regular automatic scanners and typically have severe business impacts, it is recommended that organizations must strongly assess the impact of such vulnerabilities while adopting recommended practices and scanning tools.

Get a quick security audit of your website for free now

We are analyzing https://example.com
Scanning target https://example.com
Scan status: In progress
Scan target: http://example.com/laskdlaksd/12lklkasldkasada.a
Date: 06/12/2022
Crashtest Security Suite will be checking for:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Complete your scan request
Please fill in your details receive the
quick security audit by email.
Security specialist is analyzing your scan report.
То verify your identity please provide your phone/mobile:
Thank you.
We have received your request.
As soon as your security audit is ready, we will notify you.