What is DOM?
The Document Object Model is a programming interface that gives developers the ability to access the document (webpage) and manipulate it by executing operations, therefore this interface defines the structure of documents by connecting the scripting language to the actual webpage.
A Simple Example of a DOM XSS attack
As an example the following HTML page (vulnerable.site/welcome.html) contains this content:
Normally, this HTML page would be used for welcoming the user, e.g.:
However, a request such as the one below would result in an XSS condition:
What are Source & Sink?
The victim’s browser receives this link, sends an HTTP request to www.vulnerable.site, and receives the above (static!) HTML page.
The victim’s browser then starts parsing this HTML into DOM. The DOM contains an object called document, which contains a property called URL, and this property is populated with the URL of the current page, as part of DOM creation.
The logic behind the DOM XSS is that an input from the user (source) goes to an execution point (sink). In the previous example, our source was document.write and the sink was alert(document.cookie).
After the malicious code is executed by the website, you can simply exploit this DOM-based cross-site scripting vulnerability to steal the cookies from the user’s browser or change the behavior of the page on the web application as you please.
How Do Attackers Exploit DOM XSS Vulnerabilities?
Any application is vulnerable to DOM-based cross-site scripting if there is an executable path via which data can develop from source to sink.
Different sources and sinks have various properties and behaviors that can impact exploitability, and determine what methods are used. Additionally, the application’s scripts might execute validation or other processing of data that must be accommodated when aiming to exploit a vulnerability.
In reality, the attacker would encode the URL payload so the script is not visible. Some browsers, for example, Mozzila may automatically encode the < and > characters in the document.URL when the URL is not directly typed in the address bar, and therefore it is not vulnerable to the attack shown in the example above.
Embedding a script directly in the HTML is just one attack access point, other scenarios do not require these characters, nor embedding the code into the URL directly. Therefore, browsers in general are not entirely immune to DOM XSS either.
Defending Against DOM XSS Attacks
DOM XSS attacks are hard to detect from the server-side, because malicious payloads typically do not reach the server and hence cannot be sanitized in the server-side code.
The root of the problem resides in the code of the page, this time in client-side code.
The same prevention techniques used for other XSS attacks can be used. The only difference is that in the case of DOM XSS, you must review and sanitize client-side code, not server-side code.
You can try the following techniques in order to defend against DOM XSS:
- – Avoid using data received from the client for client-side sensitive actions such as rewriting or redirection.
- – Sanitize client-side code by inspecting references to DOM objects that pose a threat, for example, URL, location, and referrer. This is especially important if DOM can be modified.
- – Use intrusion prevention systems that can inspect inbound URL parameters and prevent the inappropriate pages to be served.
Did you know that DOM XSS Detection can be automated now?
As the world’s first AI-powered Application Testing Solution NeuraLegion’s NexPloit is capable of effectively detecting DOM XSS attacks so you can enhance your security and remove threats before they become a problem for you, your business and your customers.