DOM BASED CROSS-SITE SCRIPTING (DOM BASED XSS)
XSS (Cross-Site Scripting)
Cross-Site Scripting (XSS) is a common type of vulnerability in web applications. While the XSS vulnerability was ranked 7th in 2017 in the OWASP Top 10 Web Security Risks table given in Image 1, it was combined in the Injection title in 2021 and ranked 3rd.
Cross-site scripting works by manipulating an XSS-vulnerable website to return malicious JavaScript to users. When malicious code is run in the victim’s browser, the attacker can completely compromise the victim’s interaction with the application.
There are three main types of XSS attacks. These are as follows:
• Reflected XSS containing malicious script from valid HTTP request
• Stored XSS containing malicious script from the website’s database
• DOM based XSS where the vulnerability is in client-side code rather than server-side code
NOTE: The reason why Cross-Site Scripting stands for XSS instead of CSS is that CSS is used as an abbreviation for Cascading Style Sheets in a different domain. 😊
In this article, let’s examine the DOM based XSS type.
Document Object Model (DOM)
At the heart of DOM XSS attacks is the Document Object Model (DOM). The DOM represents the structure of an HTML or XML document and provides a programming interface for web developers to dynamically change the content, structure, and style of web pages using JavaScript. You can examine the DOM structure given in Image 2 below.
DOM Based XSS
DOM based XSS stands for DOM based Cross-Site Scripting. DOM based XSS, a type of cross-site scripting vulnerability, occurs on the client side of web applications. While the vulnerability in other XSS types is in server-side processing, the vulnerability in DOM based XSS, unlike these types, is caused by incorrect handling of user input within JavaScript code that changes the Document Object Model (DOM) of a web page.
The DOM represents the structure of a web page and JavaScript is mostly used to dynamically change it. However, if adequate precautions are not taken before user input is added to the DOM, an attacker can inject malicious code that will be executed on the web page by the victim’s browser. This allows the attacker to bypass server-side security measures and perform various malicious activities.
The DOM based XSS vulnerability exploits vulnerabilities resulting from incorrect handling of user input within JavaScript code that interacts with the DOM. Injection points can occur anywhere user input is included in the DOM, such as input fields, URL parameters, fragments, or data from external sources or APIs.
Attackers exploit these injection points by injecting malicious code, often in JavaScript form, into the DOM. The injected code is then executed by the victim’s browser in the context of the web page, leading to the desired malicious result.
Difference of DOM Based XSS from Other XSS Types
DOM XSS differs from familiar XSS in several ways. While classic(stored and reflected) XSS vulnerabilities are exposed on the server side, DOM XSS exploits vulnerabilities in JavaScript code execution on the client side. Classic XSS involves injecting malicious code from the server that is reflected back to users, while DOM XSS manipulates the DOM through script execution directly on the client side.
Another distinction concerns the context of execution. Classic XSS executes the code injected within the server’s response, affecting all users accessing the vulnerable page. In contrast, DOM XSS executes malicious code in the victim’s browser during dynamic manipulation of the DOM. This means that DOM XSS attacks can be more targeted and affect individual users rather than the entire user base.
Impact of XSS Vulnerabilities
When an XSS attack is made, the attacker can perform the events mentioned below ( with the limitation of javascript ).
- Impersonate or impersonate the victim
- Can perform any action that the user can take
- Can access all data that the user has access to
- Capture the user’s login credentials
- Can alter the original website
- Can inject Trojan functionality into the website
- Attacker can takeover users’ browser with browser exploitation
The actual impact of an XSS attack may vary depending on the nature, functionality and data of the application and the status of the compromised user. In an application that handles sensitive data such as banking transactions, emails or health records, it has a huge impact. If the application has elevated privileges, the impact is often critical, allowing an attacker to take full control of the vulnerable application and compromise all users and their data.
Preventing XSS Attacks
Effectively preventing XSS vulnerabilities can include a combination of the following measures.
· Add as strict filtering to user data entry points as possible. At the point where the user logs in, filter as tightly as possible based on expected or valid input.
· At the point in HTTP responses of user-controllable data, encode the data in the output. Depending on the output content, this may require coding combinations of HTML, URL, JavaScript and CSS to be applied.
· Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
· You can use the Content Security Policy (CSP) to reduce the severity of the XSS vulnerability.
Also, effects of XSS attack can be restricted with other security measurements like:
· Enabling HTTPONLY flag on cookies for making harder javascript to access cookie
· Disabling “trace” method for preventing against cross site tracing attack
· Using CSRF tokens in important forms to prevent CSRF attacks over XSS
Click here to review and solve the example about DOM XSS from Burp Academy.
I would like to thank Merve SARICAOĞLU and Kubilay Berk ALKAN for their contributions.
For more information on DOM Based XSS, see the references.
You can access my other articles here 😊
Seda BOLAT
