DOM Based Cross Site Scripting
XSS of the Third Kind
A look at an overlooked flavor of XSS
Amit Klein, July 2005
Last modified: 4th of July, 2005
Application developers and owners need to understand DOM Based XSS, as it represents a threat to the web application, which has different preconditions than standard XSS. As such, there are many web applications on the Internet that are vulnerable to DOM Based XSS, yet when tested for (standard) XSS, are demonstrated to be “not vulnerable”. Developers and site maintainers (and auditors) need to familiarize themselves with techniques to detect DOM Based XSS vulnerabilities, as well as with techniques to defend against them, both therewhich are different than the ones applicable for standard XSS.
Example and Discussion
Before describing the basic scenario, it is important to stress that the techniques outlined here were already demonstrated in public (e.g. ,  and ). As such, it is not claimed that the below are new techniques (although perhaps some of the evasion techniques are).
The prerequisite is for the vulnerable site to have an HTML page that uses data from the document.location or document.URL or document.referrer (or any various other objects which the attacker can influence) in an insecure manner.
In analogy to the example in  (and as an essentially identical scenario to the one in ), consider, for example, the following HTML page (let’s say this is the content of http://www.vulnerable.site/welcome.html):
Welcome to our system
Normally, this HTML page would be used for welcoming the user, e.g.:
However, a request such as:
1. The malicious payload was not embedded in the raw HTML page at any time (unlike the other flavors of XSS).
2. This exploit only works if the browser does not modify the URL characters. Mozilla automatically encodes < and > (into %3C and %3E, respectively) in the document.URL when the URL is not directly typed at the address bar, and therefore it is not vulnerable to the attack as shown in the example. It is vulnerable to attacks if < and > are not needed (in raw form). Microsoft Internet Explorer 6.0 does not encode < and >, and is therefore vulnerable to the attack as-is.
Of course, embedding in the HTML directly is just one attack mount point, there are various scenarios that do not require < and >, and therefore Mozilla in general is not immune from this attack.
Evading standard detection and prevention technologies
In the above example, it may be argued that still, the payload did arrive to the server (in the query part of the HTTP request), and so it can be detected just like any other XSS attack. But even that can be taken care of. Consider the following attack:
Notice the number sign (#) right after the file name. It tells the browser that everything beyond it is a fragment, i.e. not part of the query. Microsoft Internet Explorer (6.0) and Mozilla do not send the fragment to the server, and therefore, the server would see the equivalent of http://www.vulnerable.site/welcome.html, so the payload would not even be seen by the server. We see, therefore, that this evasion technique causes the major browsers not to send the malicious payload to the server.
Sometimes, it’s impossible to completely hide the payload: in  and , the malicious payload is part of the username, in a URL that looks like http://username@host/. The browser, in such case, sends a request with Authorization header containing the username (the malicious payload), and thus, the payload does arrive to the server (Base64 encoded - so IDS/IPS would need to decode this data first in order to observe the attack). Still, the server is not required to embed this payload in order for the XSS condition to occur.
Obviously, in situations where the payload can be completely hidden, online detection (IDS) and prevention (IPS, web application firewalls) products cannot fully defend against this attack, assuming the vulnerable script can indeed be invoked from a known location. Even if the payload has to be sent to the server, in many cases it can be crafted in such way to avoid being detected, e.g. if a specific parameter is protected (e.g. the name parameter in the above example), then a slight variation of the attack may succeed:
A more strict security policy would require that the name parameter be sent (to avoid the above tricks with names and number sign). We can therefore send this:
If the policy restricts the additional parameter name (e.g. to foobar), then the following variant would succeed:
Note that the ignored parameter (foobar) must come first, and it contains the payload in its value.
Even if the payload is inspected by the server, protection can be guaranteed only if the request in its fullness is denied, or if the response is replaced with some error text. Consider  and  again, if the Authorization header is simply removed by an intermediate protection system, it has no effect as long as the original page is returned. Likewise, any attempt to sanitize the data on the server, either by removing the offending characters or by encoding them, is ineffective against this attack.
In the case of document.referrer, the payload is sent to the server through the Referer header. However, if the user’s browser, or an intermediate device eliminates this header, then there’s no trace of the attack - it may go completely unnoticed.
To generalize, traditional methods of:
Do not work well against DOM Based XSS.
1. Avoiding client side document rewriting, redirection, or other sensitive actions, using client side data. Most of these effects can be achieved by using dynamic pages (server side).
Note that a document object property or a window object property may be referenced syntactically in many ways - explicitly (e.g. window.location), implicitly (e.g. location), or via obtaining a handle to a window and using it (e.g. handle_to_some_window.location).
Special attention should be given to scenarios wherein the DOM is modified, either explicitly or potentially, either via raw access to the HTML or via access to the DOM itself, e.g. (by no means an exhaustive list, there are probably various browser extensions):
To continue the above example, an effective defense can be replacing the original script part with the following code, which verifies that the string written to the HTML page consists of alphanumeric characters only:
3. Employing a very strict IPS policy in which, for example, page welcome.html is expected to receive a one only parameter named “name”, whose content is inspected, and any irregularity (including excessive parameters or no parameters) results in not serving the original page, likewise with any other violation (such as an Authorization header or Referer header containing problematic data), the original content must not be served. And in some cases, even this cannot guarantee that an attack will be thwarted.
A note about redirection vulnerabilities
The above discussion is on XSS, yet in many cases, merely using a client side script to (insecurely) redirect the browser to another location is considered vulnerability in itself. In such cases, the above techniques and observations still apply.
While most XSS attacks described in public do indeed depend on the server physically embedding user data into the response HTML pages, there are XSS attacks that do not rely on server side embedding of the data. This has material significance when discussing ways to detect and prevent XSS. To date, almost all detection and prevention techniques discussed in public assume that XSS implies that the server receives malicious user input and embeds it in an HTML page. Since this assumption doesn’t hold (or only very partially holds) for the XSS attacks described in this paper, many of the techniques fail to detect and prevent this kind of attacks.
The XSS attacks that rely on server side embedding of user data are categorized into “non-persistent” (or “reflected”) and “persistent” (or “stored”). It is thus suggested that the third kind of XSS, the one that does not rely on server side embedding, be named “DOM Based XSS”.
Here is a comparison between standard XSS and DOM Based XSS:
DOM Based XSS
Insecure embedding of client input in HTML outbound page
Insecure reference and use (in a client side code) of DOM objects that are not fully controlled by the server provided page
Web developer (CGI)
Web developer (HTML)
Dynamic only (CGI script)
Typically static (HTML), but not necessarily.
If evasion techniques are applicable and used - no server side detection is possible
Note: the URLs below are up to date at the time of writing (July 4th, 2005). Some of these materials are live documents, and as such may be updated to reflect the insights of this paper.
 “CERT Advisory CA-2000-02 - Malicious HTML Tags Embedded in Client Web Requests”, CERT, February 2nd, 2000
 “Cross Site Scripting Explained”, Amit Klein, June 2002
 “Cross-Site Scripting”, Web Application Security Consortium, February 23rd, 2004
 “Cross Site Scripting (XSS) Flaws”, The OWASP Foundation, updated 2004 http://www.owasp.org/documentation/topten/a4.html
 “Thor Larholm security advisory TL#001 (IIS allows universal CrossSiteScripting)”, Thor Larholm, April 10th, 2002
(see also Microsoft Security Bulletin MS02-018 http://www.microsoft.com/technet/security/bulletin/MS02-018.mspx)
 “ISA Server Error Page Cross Site Scripting”, Brett Moore, July 16th, 2003 http://www.security-assessment.com/Advisories/ISA%20XSS%20Advisory.pdf
(see also Microsoft Security Bulletin MS03-028 http://www.microsoft.com/technet/security/bulletin/MS03-028.mspx and a more elaborate description in “Microsoft ISA Server HTTP error handler XSS”, Thor Larholm, July 16th, 2003 http://www.securityfocus.com/archive/1/329273)
 “Bugzilla Bug 272620 - XSS vulnerability in internal error messages”, reported by Michael Krax, December 23rd, 2004
 “The Cross Site Scripting FAQ”, Robert Auger, May 2002 (revised August 2003)
About the author
Amit Klein is a renowned web application security researcher. Mr. Klein has written many research papers on various web application technologies--from HTTP to XML, SOAP and web services--and covered many topics--HTTP request smuggling, insecure indexing, blind XPath injection, HTTP response splitting, securing .NET web applications, cross site scripting, cookie poisoning and more. His works have been published in Dr. Dobb's Journal, SC Magazine, ISSA journal, and IT Audit journal; have been presented at SANS and CERT conferences; and are used and referenced in many academic syllabi.
Mr. Klein is WASC (Web Application Security Consortium) member.