This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
DOM based XSS Prevention Cheat Sheet
Introduction
When looking at XSS (Cross Site Scripting) there are three generally recognized forms of XSS. Reflected, Persisted, and DOM based XSS. The XSS Prevention Cheatsheet has done an excellent job of addressing Reflected and Persisted XSS. This cheatsheet will address DOM (Document Object Model) based XSS and is an extension (as assumes comprehension of) the the XSS Prevention Cheatsheet .
In order to understand DOM based XSS one needs to see the fundamental difference between reflected and persisted XSS when compared to DOM based XSS. Reflected and persisted XSS exist in a higher level rendering context and DOM based XSS is primarily found in a lower level execution context. A rendering context is associated with the parsing of HTML tags and their attributes. The HTML parser of the rendering context dictates how data is presented and laid out on the page and can be further broken down into the standard contexts of HTML, HTML attribute, URL, and CSS. The JavaScript or VBScript parser of an execution context is associated with the parsing and execution of script code. Each parser has distinct and separate semantics in the way they can possibly execute script code (XSS) which make creating consistent rules for mitigating both rendering and execution based contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each sub context (HTML, HTML attribute, URL, and CSS) within the execution context. One consistency, however, is the need to JavaScript encode in additional encodings required for the sub context in the execution context. Let’s look at the individual sub contexts of the execution context in turn.
HTML Sub Context within the Execution Context
There are several methods and attributes which can be used to directly render HTML execution content within JavaScript.
Attributes
element.innerHTML = “<HTML> Tags and markup”;
element.outerHTML = “<HTML> Tags and markup”;
Methods
document.write(“<HTML> Tags and markup”);
document.writeln(“<HTML> Tags and markup”);
Guideline
In a pure HTML execution context (not HTML Attribute) use HTML and JavaScript encoding to mitigate against attacks.
element.innerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
element.outerHTML = “<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”;
Methods
document.write(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);
</code>document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);</code>
HTML Attribute Sub Context within the Execution Context
The HTML attribute Sub Context within the Execution context is divergent from the standard encoding rules. This is because the rule to HTML attribute encode in an HTML attribute rendering context is mitigating attacks which try to exit out of the attribute to add additional attributes and/or tags which could have executable code. When you are in a DOM execution context you only need to JavaScript encode HTML attributes which do not execute code (attributes other than event handler, CSS, and URL attributes).
For example, the general rule is to HTML Attribute encode untrusted data (data from the database, http request, user, backend system, etc.) placed in an HTML Attribute. This is the appropriate step to take when outputting data in a rendering context, however using HTML Attribute encoding in an execution context will break the application display of data.
var x = document.createElement(“input”);
x.setAttribute(“name”, “company_name”);
x.setAttribute(“value”, ‘<%=Encoder.encodeForJS(Encoder.encodeForHTMLAttr(companyName))%>’);
var form1 = document.forms[0];
form1.appendChild(x);
The problem is that if companyName had the value “Johnson & Johnson”. What would be displayed in the input text field would be “Johnson & Johnson”. The appropriate encoding to use in the above case would be only JavaScript encoding to disallow an attacker from closing out the single quotes and in-lining code.
var x = document.createElement(“input”);
x.setAttribute(“name”, “company_name”);
x.setAttribute(“value”, ‘<%=Encoder.encodeForJS(companyName)%>’);
var form1 = document.forms[0];
form1.appendChild(x);
It is important to note that when setting an HTML attribute which does not execute code the value is set directly within the object attribute of the HTML element so there is no concerns with injecting up.
