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

From OWASP
Revision as of 06:07, 15 February 2011 by Abraham Kang (talk | contribs) (DOM based XSS Cheatsheet)

Jump to: navigation, search

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.

This paper refers to the HTML, HTML attribute, URL, and CSS Cheatsheet contexts as subcontexts because each of these contexts can be reached and set within a JavaScript execution context. In JavaScript code the main context is JavaScript but since an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods we refer to the other contexts besides the JavaScript context as sub contexts.

The following example of an attack which occurs in the JavaScript context and HTML sub context:

<script>
var x = ‘<%= htmlAndJavaScriptEncodedVar %>’;
var d = document.createElement(‘div’);
d.innerHTML = x;
document.body.appendChild(d);
</script>


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))%>”);
document.writeln(“<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>”);

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.

URL Attribute Sub Context within the Execution Context

The logic which parses URLs in both execution and rendering contexts looks to be the same. Therefore there is little change in the encoding rules for URL attributes in an execution (DOM) context.

<code>var x = document.createElement(“a”);
x.setAttribute(“href”, ‘<%=Encoder.encodeForJS(Encoder.encodeForURL(companyName))%>’);
var y = document.createTextElement(“Click Me To Test”);
x.appendChild(y);
document.body.appendChild(x);

If you utilize fully qualified URLs then this will break the links as the colon in the protocol identifier (“http:” or “javascript:”) will be URL encoded preventing the “http” and “javascript” protocols from being invoked.

CSS Attribute Sub Context within the Execution Context

Normally executing JavaScript from a CSS context required either passing “javascript:attackCode()” to the CSS url() method or invoking the CSS expression() method passing JavaScript code to be directly executed. From my experience, calling the expression() function from an execution context (JavaScript) has been disabled. In order to mitigate against the CSS url() method ensure that you are URL encoding the data passed to the CSS url() method.

document.body.style.backgroundImage = "url(<%=Encoder.encodeForJS(Encoder.encodeForURL(companyName))%>)";

TODO: We have not been able to get the expression() function working from DOM JavaScript code. Need some help.

Event Handler and JavaScript code Sub Contexts within an Execution Context

Putting dynamic data within JavaScript code is especially dangerous because JavaScript encoding has different semantics for JavaScript encoded data when compared to other encodings. In many cases, JavaScript encoding does not stop attacks within an execution context. For example, a JavaScript encoded string will execute even though it is JavaScript encoded.

var x = document.createElement("a");
x.href="#”;
x.setAttribute("onclick", "\u0061\u006c\u0065\u0072\u0074\u0028\u0032\u0032\u0029");
var y = document.createTextNode("Click To Test");
x.appendChild(y);
document.body.appendChild(x);

JavaScript event handler methods are dangerous because they implicitly do an eval() on the data passed to the DOM attribute. There are other places in JavaScript where JavaScript encoding is accepted as valid executable code.

for ( var \u0062=0; \u0062 < 10; \u0062++){
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065\u006c\u006e
("\u0048\u0065\u006c\u006c\u006f\u0020\u0057\u006f\u0072\u006c\u0064");
}
\u0077\u0069\u006e\u0064\u006f\u0077
.\u0065\u0076\u0061\u006c (
\u0064\u006f\u0063\u0075\u006d\u0065\u006e\u0074
.\u0077\u0072\u0069\u0074\u0065(111111111));

or

var s = "\u0065\u0076\u0061\u006c";
var t = "\u0061\u006c\u0065\u0072\u0074\u0028\u0031\u0031\u0029";
window[s](t);

JavaScript encoding enables the support of international characters in programming constructs and variables as well as well as alternate string representations (string escapes).

However the opposite is the case with HTML encoding.

HTML Encoding’s Disarming Nature

In general, HTML encoding servers to castrate HTML tags which are placed in HTML and HTML attribute contexts. Working example:

<a href=…>

Normally encoded example (Does Not Work – DNW):

&#x3c;a href=… &#x3e;

HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW):

<&#x61; href=…>

Guidelines for Developing Secure Applications Utilizing JavaScript

DOM based XSS is extremely difficult to mitigate against because of its large attack surface and lack of standardization across browsers. The guidelines below are an attempt to provide guidelines for developers when developing Web based JavaScript applications such that they can avoid XSS.

  1. Data should only be displayed as displayable text. Never treat untrusted data as code or markup within JavaScript code.
  2. Always JavaScript encode and delimit untrusted data as quoted strings when entering the application (Jim Manico and Robert Hansen)
    1. var x = “<%=encodedJavaScriptData%>”;
    2. setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
  3. Use document.createElement(“…”), element.setAttribute(“…”,”value”), element.appendChild(…), etc. to build dynamic interfaces. Avoid use of HTML rendering methods:
    1. <code>element.innerHTML = “…”;
    2. <code>element.outerHTML = “…”;
    3. <code>document.write(…);
    4. <code>document.writeln(…);
  4. Understand the dataflow of untrusted data through your JavaScript code. If you do have to use the methods above remember to HTML and them JavaScript encode the untrusted data (Stefano Di Paola).
  5. There are numerous methods which implicitly eval() data passed to it. Make sure that any untrusted data passed to these methods is delimited with string delimiters, double JavaScript encoded, and wrapped in a custom function. Ensure to follow step 4 above to make sure that the untrusted data is not sent to dangerous methods within the custom function.
    1. setTimeout(“customFunction(‘<%=doubleJavaScriptEncodedData%>’, y)”);
  6. Limit the usage of dynamic untrusted data to right side operations. And be aware of data which may be passed to the application which look like code (eg. “location”, “eval”). (Achim)#
    1. var x = “<%=properly encoded data for flow%>”;
    2. if you want to change different object attributes based on user input instead of:
    3. window[userData] = “moreUserData”;
  7. Use the following methods when placing dynamic untrusted data in right side operations.
    1. if (userData===”location”) {
    2. window.location = “static/path/or/properly/url/encoded/value”;
  8. When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike from Google).
  9. Limit access to properties objects when using object[x] accessors. (Mike from Google). In other words use a level of indirection between untrusted input and specified object properties.
  10. Run your JavaScript in a ECAM5 canopy or sand box to make it harder for your JavaScript API to be compromised (Gaz Hayzes and John Stevens).
  11. Don’t eval() JSON to convert it to native JavaScript objects. Instead use JSON.toJSON() and JSON.parse() (Chris Schmidt).


Special thanks to Gaz Hayes, Stefano di Paola, Robert Hansen, Mario H, Achim, John Stevens, Edwardo (SirDarkCat), Chris Schmidt, Mike from Google, and many others who help make this guide possible

Retrieved from "https://wiki.owasp.org/index.php?title=DOM_based_XSS_Prevention_Cheat_Sheet&oldid=105109"