Understanding DOM based XSS in DVWA

Cross-site Scripting (XSS) is a well-known web application vulnerability among developers, so there is no need to explain what XSS is. The most important part of a Cross-site Scripting attack developers should understand is its impact; an attacker can steal or hijack your session, carry out very successful phishing attacks and effectively can do anything that the victim can.

Let us first see what is DOM XSS?

In order to understand DOM XSS, we need to describe a bit what DOM is, and why is it relevant to this context. The Document Object Model is a convention for representing and working with objects in an HTML document (as well as in other document types). Basically all HTML documents have an associated DOM, consisting of objects representing the document properties from the point of view of the browser.

DOM XSS is a type of cross site scripting attack which relies on inappropriate handling, in the HTML page, of the data from its associated DOM. Among the objects in the DOM, there are several which the attacker can manipulate in order to generate the XSS condition, and the most popular, from this perspective, are the document.url, document.location and document.referrer objects.

Simple DOM Based Cross-site Scripting Vulnerability Example:

Let’s take the basic example of a page which provides users with customized content, depending on their user name which is encoded in the URL, and uses their name on the resulting page:

In this case the HTML source of http://www.example.com/userdashboard.html would look like this:

The result of http://www.example.com/userdashboard.html?context=Mary would be a customized dashboard for Mary, containing the string “Main Dashboard for Mary” at the top.

The malicious script can be embedded in the URL as follows:

Furthermore, the victim’s browser receives the above URL and sends a HTTP request to http://www.example.com, receiving the static HTML page described above. Then, the browser starts building the DOM of the page, and populates the document.url property, of the document object with the URL containing the malicious script.

When the browser arrives to the script which gets the user name from the URL, referencing the document.urlproperty, it runs it and consequently updates the raw HTML body of the page, resulting in

Next, the browser finds the malicious code in the HTML body and executes it, thus finalizing the DOM XSS attack. In reality, the attacker would hide the contents of the payload in the URL using encoding so that it is not obvious that the URL contains a script.

Note however, that some browsers may encode the < and > characters in the URL, causing the attack to fail. However there are other scenarios which do not require the use of these characters, nor embedding the code into the URL directly, so these browsers are not entirely immune to this type of attack either.

How is DOM XSS different?

Using the above example, we can observe that:

1. The HTML page is static, and there is no malicious script embedded into the page, as in the case of other types of XSS attacks;
2. The script code never gets to the server, if the “#” character is used; it is seen as fragment and the browser does not forward it further. Hence server-side attack detection tools will fail to detect this attack; in some cases, depending on the type of the URL, the payload might get to the server and it may be impossible to hide it.

Defending against DOM XSS attacks

The best way to fix DOM based cross-site scripting is to use the right output method (sink). For example if you want to use user input to write in a <div> element don't use innerHtml, instead use innerText/textContent. This will solve the problem, and it is the right way to remediate DOM based XSS vulnerabilities.

Effective conceptual defense methods against the DOM XSS include, but are not limited to

1. Avoiding client-side sensitive actions such as rewriting or redirection, using client-side data;
2. Sanitization of the client-side code by inspecting and securely handling references to DOM objects that pose a threat, such as url, location and referrer, especially in cases when the DOM may be modified;
3. Using intrusion prevention systems which are able to inspect inbound URL parameters and prevent the inappropriate pages to be served.

Attack Characteristic	Classic XSS	DOM XSS
Root cause	Source code	Source code
Premises	Inappropriate embedding of client side data in outbound HTML pages (by the server).	Inappropriate referencing and use in the client-side code, of DOM objects which are not entirely controlled and verified by the server-generated HTML pages.
Page type	Dynamic	Static or Dynamic
Detection	Intrusion detection systems, logs	Cannot be detected server side, if proper evading techniques are being used by the attacker.
Detection of vulnerabilities	Attack simulation;	Attack simulation;
	Code review – server-side;	Code review – client-side;
	Vulnerability detection tools that perform automatic penetration testing	Vulnerability detection tools that perform automatic penetration testing
Defending	Sanitization – server side	Sanitization – client-side
	Intrusion prevention systems	Intrusion prevention systems –to a lesser extent