DOM Based XSS
Thank you for visiting OWASP.org. We recently migrated our community to a new web platform and regretably the content for this page needed to be programmatically ported from its previous wiki page. There’s still some work to be done.
This is an example of a Project or Chapter Page.
DOM Based XSS
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.
This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed in the response page (due to a server side flaw).
Please note research from David Wichers seeking to reclassify DOM XSS more strictly as CLIENT SIDE XSS. https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#DOM_Based_XSS_.28AKA_Type-0.29
Suppose the following code is used to create a form to let the user choose his/her preferred language. A default language is also provided in the query string, as the parameter “default”.
… Select your language: <select><script> document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>"); document.write("<OPTION value=2>English</OPTION>"); </script></select> …
The page is invoked with a URL such as:
A DOM Based XSS attack against this page can be accomplished by sending the following URL to a victim:
When the victim clicks on this link, the browser sends a request for:
Note that the HTTP response sent from the server does not contain the attacker’s payload. This payload manifests itself at the client-side script at runtime, when a flawed script accesses the DOM variable document.location and assumes it is not malicious.
Advanced Techniques and Derivatives
In the example above, while the payload was not embedded by the server in the HTTP response, it still arrived at the server as part of an HTTP request, and thus the attack could be detected at the server side. The “DOM Based XSS” paper () details a technique to avoid server side detection. It also describes several other possible locations for the payload, besides document.location.
The technique to avoid sending the payload to the server hinges on the fact that URI fragments (the part in the URI after the “#”) is not sent to the server by the browser. Thus, any client side code that references, say, document.location, may be vulnerable to an attack which uses fragments, and in such case the payload is never sent to the server. For example, the above DOM based XSS can be modified into:
which mounts the same attack without it being seen by the server (which will simply see a request for page.html without any URL parameters).
then a victim using an un-patched Acrobat reader would succumb to the attack. Adobe patched their reader after they were made aware of this flaw, but if not all users have downloaded the patch then those users are still vulnerable to this type of attack.
Ivan Ristic did some research and proposed some server side defenses against this type of attack in his presentation “Protecting Web Applications from Universal PDF XSS: A discussion of how weird the web application security world has become” at the 2007 OWASP Europe AppSec Conference in Milan. His presentation () can be downloaded here.
Kuza55 and Stefano Di Paola discussed more ways in which the concept of DOM manipulation and DOM based XSS can be extended in .
Testing Tools and Techniques
Minded Security has been doing some significant research into DOM based XSS. They are working on two projects to help with DOM Based XSS:
See: https://dominator.mindedsecurity.com/ (https://github.com/wisec/DOMinator for the open source part)
2. The DOM XSS Wiki - The start of a Knowledgebase for defining sources of attacker controlled inputs and sinks which could potentially introduce DOM Based XSS issues. Its very immature as of 11/17/2011. Please contribute to this wiki if you know of more dangerous sinks and/or safe alternatives!!
3. DOM Snitch - An experimental Chrome extension that enables developers and testers to identify insecure practices commonly found in client-side code. From Google.
 “DOM Based Cross Site Scripting or XSS of the Third Kind” (WASC writeup), Amit Klein, July 2005
 “Attacking Rich Internet Applications” (RUXCON 2008 presentation), Kuza55 and Stefano Di Paola, November 2008
 “Subverting Ajax” (23C3 presentation), Stefano Di Paola and Giorgio Fedon, December 2006
 “Protecting Web Applications from Universal PDF XSS” (2007 OWASP Europe AppSec presentation) Ivan Ristic, May 2007
 OWASP Testing Guide