CS-DOM_based_XSS_Prevention DOM based XSS Prevention Cheat Sheet

Commonly discussed, overlapping categories of XSS (Cross-Site Scripting) include: • Reflected or Stored • DOM Based XSS. The XSS Prevention Cheatsheet does an excellent job of addressing Reflected and Stored XSS. This cheatsheet addresses DOM (Document Object Model) based XSS and is an extension (and assumes comprehension) of the XSS Prevention Cheatsheet. Stored and reflected describe how an attack payload reaches a victim; server-side and client-side describe where untrusted data is handled unsafely. Both stored and reflected XSS can occur on the client or server, including stored and reflected DOM-based XSS. For server-side XSS, the server inserts untrusted data into a response without making it safe for its output context. DOM-based XSS arises from unsafe client-side processing. In either case, the injected script executes in the browser; choose controls for the actual data flow and output context. When a browser is rendering HTML and any other associated content like CSS or JavaScript, it identifies various rendering contexts for the different kinds of input and follows different rules for each 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 which make creating consistent rules for mitigating vulnerabilities in various contexts difficult. The complication is compounded by the differing meanings and treatment of encoded values within each subcontext (HTML, HTML attribute, URL, and CSS) within the execution context. For the purposes of this article, we refer to the HTML, HTML attribute, URL, and CSS 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 with the right tags and context closing characters, an attacker can try to attack the other 4 contexts using equivalent JavaScript DOM methods. The following is an example vulnerability which occurs in the JavaScript context and HTML subcontext: ```html var x = ''; var d = document.createElement('div'); d.innerHTML = x; document.body.appendChild(d); ``` Let's look at the individual subcontexts of the execution context in turn.

There are several methods and attributes which can be used to directly render HTML content within JavaScript. These methods constitute the HTML Subcontext within the Execution Context. If these methods are provided with untrusted input, then an XSS vulnerability could result. For example: Example Dangerous HTML Methods Attributes ```javascript element.innerHTML = " Tags and markup"; element.outerHTML = " Tags and markup"; ``` Methods ```javascript document.write(" Tags and markup"); document.writeln(" Tags and markup"); ``` Guideline To make dynamic updates to HTML in the DOM safe, we recommend: 1. HTML encoding, and then 2. JavaScript encoding all untrusted input, as shown in these examples: ```javascript var ESAPI = require('node-esapi'); element.innerHTML = ""; element.outerHTML = ""; ``` ```javascript var ESAPI = require('node-esapi'); document.write(""); document.writeln(""); ```

The HTML attribute *subcontext* 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 necessary in order to mitigate attacks which try to exit out of an HTML attributes or try to add additional attributes which could lead to XSS. 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, back-end 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. SAFE but BROKEN example ```javascript var ESAPI = require('node-esapi'); var x = document.createElement("input"); x.setAttribute("name", "company_name"); // In the following line of code, companyName represents untrusted user input // The ESAPI.encoder().encodeForHTMLAttribute() is unnecessary and causes double-encoding x.setAttribute("value", ''); 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, or escaping to HTML and opening a new script tag. SAFE and FUNCTIONALLY CORRECT example ```javascript var ESAPI = require('node-esapi'); var x = document.createElement("input"); x.setAttribute("name", "company_name"); x.setAttribute("value", ''); 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.

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. Therefore, the primary recommendation is to avoid including untrusted data in this context. If you must, the following examples describe some approaches that do and do not work. ```javascript var x = document.createElement("a"); x.href="#"; // In the line of code below, the encoded data on the right (the second argument to setAttribute) // is an example of untrusted data that was properly JavaScript encoded but still executes. 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); ``` The `setAttribute(name_string,value_string)` method is dangerous because it implicitly coerces the *value_string* into the DOM attribute datatype of *name_string*. In the case above, the attribute name is an JavaScript event handler, so the attribute value is implicitly converted to JavaScript code and evaluated. In the case above, JavaScript encoding does not mitigate against DOM based XSS. Other JavaScript methods that interpret strings as code, such as `setTimeout`, `setInterval`, and `Function`, have the same risk. HTML event-handler attributes also contain JavaScript function bodies. Escaping every character in one payload may produce a syntax error, but JavaScript encoding is not a defense for this context: escaped identifiers remain executable when the surrounding syntax is valid. ```html Test Me ``` Setting the JavaScript `onclick` property is different from setting an HTML attribute. It expects a callback; assigning a primitive string sets it to null, whether or not the string is encoded. This is type conversion, not a benefit of JavaScript encoding. Assign a trusted function, and keep untrusted values as data inside that function rather than compiling them as code. ```html Test Me ``` ```javascript // Neither string becomes a handler. document.getElementById("bb").onclick = "alert(7)"; document.getElementById("bb").onclick = "\u0061\u006c\u0065\u0072\u0074\u0028\u0037\u0029"; // A trusted function is a handler. document.getElementById("bb").onclick = function () { alert("I was called."); }; ``` There are other places in JavaScript where JavaScript encoding is accepted as valid executable code. ```javascript for(var \u0062=0; \u0062 ` tag for example. HTML Encoding's Disarming Nature In general, HTML encoding serves to castrate HTML tags which are placed in HTML and HTML attribute contexts. Working example (no HTML encoding): ```html ``` Normally encoded example (Does Not Work – DNW): ```html <a href=... > ``` HTML encoded example to highlight a fundamental difference with JavaScript encoded values (DNW): ```html ``` If HTML encoding followed the same semantics as JavaScript encoding, the line above could have possibly worked to render a link. This difference makes JavaScript encoding a less viable weapon in our fight against XSS.

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. ```javascript var ESAPI = require('node-esapi'); document.body.style.backgroundImage = "url()"; ```

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. ```javascript var ESAPI = require('node-esapi'); var x = document.createElement("a"); x.setAttribute("href", ''); 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.

The most fundamental safe way to populate the DOM with untrusted data is to use the safe assignment property `textContent`. Here is an example of safe usage. ```html element.textContent = untrustedData; //does not execute code ```

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 tag` element don't use `innerHtml`, instead use `innerText` or `textContent`. This will solve the problem, and it is the right way to re-mediate DOM based XSS vulnerabilities. It is always a bad idea to use a user-controlled input in dangerous sources such as eval. 99% of the time it is an indication of bad or lazy programming practice, so simply don't do it instead of trying to sanitize the input. Finally, to fix the problem in our initial code, instead of trying to encode the output correctly which is a hassle and can easily go wrong we would simply use `element.textContent` to write it in a content like this: ```html Current URL: ... document.getElementById("contentholder").textContent = document.baseURI; ``` It does the same thing but this time it is not vulnerable to DOM based cross-site scripting vulnerabilities.

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 (Web 2.0) such that they can avoid XSS. GUIDELINE \#1 - Untrusted data should only be treated as displayable text Avoid treating untrusted data as code or markup within JavaScript code. GUIDELINE \#2 - Always JavaScript encode and delimit untrusted data as quoted strings when entering the application when building templated JavaScript Always JavaScript encode and delimit untrusted data as quoted strings when entering the application as illustrated in the following example. ```javascript var x = ""; ``` GUIDELINE \#3 - Use document.createElement("..."), element.setAttribute("...","value"), element.appendChild(...) and similar to build dynamic interfaces `document.createElement("...")`, `element.setAttribute("...","value")`, `element.appendChild(...)` and similar are safe ways to build dynamic interfaces. Please note, `element.setAttribute` is only safe for a limited number of attributes. Dangerous attributes include any attribute that is a command execution context, such as `onclick` or `onblur`. Examples of safe attributes includes: `align`, `alink`, `alt`, `bgcolor`, `border`, `cellpadding`, `cellspacing`, `class`, `color`, `cols`, `colspan`, `coords`, `dir`, `face`, `height`, `hspace`, `ismap`, `lang`, `marginheight`, `marginwidth`, `multiple`, `nohref`, `noresize`, `noshade`, `nowrap`, `ref`, `rel`, `rev`, `rows`, `rowspan`, `scrolling`, `shape`, `span`, `summary`, `tabindex`, `title`, `usemap`, `valign`, `value`, `vlink`, `vspace`, `width`. GUIDELINE \#4 - Avoid sending untrusted data into HTML rendering methods Avoid populating the following methods with untrusted data. 1. `element.innerHTML = "...";` 2. `element.outerHTML = "...";` 3. `document.write(...);` 4. `document.writeln(...);` GUIDELINE \#5 - Avoid the numerous methods which implicitly eval() data passed to it There are numerous methods which implicitly `eval()` data passed to it that must be avoided. Make sure that any untrusted data passed to these methods is: 1. Delimited with string delimiters 2. Enclosed within a closure or JavaScript encoded to N-levels based on usage 3. Wrapped in a custom function. Ensure to follow step 3 above to make sure that the untrusted data is not sent to dangerous methods within the custom function or handle it by adding an extra layer of encoding. Utilizing an Enclosure (as suggested by Gaz) The example that follows illustrates using closures to avoid double JavaScript encoding. ```javascript var ESAPI = require('node-esapi'); setTimeout((function(param) { return function() { customFunction(param); } })(""), y); ``` The other alternative is using N-levels of encoding. N-Levels of Encoding If your code looked like the following, you would need to only double JavaScript encode input data. ```javascript setTimeout("customFunction('', y)"); function customFunction (firstName, lastName) alert("Hello" + firstName + " " + lastName); } ``` The `doubleJavaScriptEncodedData` has its first layer of JavaScript encoding reversed (upon execution) in the single quotes. Then the implicit `eval` of `setTimeout` reverses another layer of JavaScript encoding to pass the correct value to `customFunction` The reason why you only need to double JavaScript encode is that the `customFunction` function did not itself pass the input to another method which implicitly or explicitly called `eval` If *firstName* was passed to another JavaScript method which implicitly or explicitly called `eval()` then `` above would need to be changed to ``. An important implementation note is that if the JavaScript code tries to utilize the double or triple encoded data in string comparisons, the value may be interpreted as different values based on the number of `evals()` the data has passed through before being passed to the if comparison and the number of times the value was JavaScript encoded. If A is double JavaScript encoded then the following if check will return false. ``` javascript var x = "doubleJavaScriptEncodedA"; //\u005c\u0075\u0030\u0030\u0034\u0031 if (x == "A") { alert("x is A"); } else if (x == "\u0041") { alert("This is what pops"); } ``` This brings up an interesting design point. Ideally, the correct way to apply encoding and avoid the problem stated above is to server-side encode for the output context where data is introduced into the application. Then client-side encode (using a JavaScript encoding library such as node-esapi) for the individual subcontext (DOM methods) which untrusted data is passed to. Here are some examples of how they are used: ```javascript //server-side encoding var ESAPI = require('node-esapi'); var input = ""; ``` ```javascript //HTML encoding is happening in JavaScript var ESAPI = require('node-esapi'); document.writeln(ESAPI.encoder().encodeForHTML(input)); ``` One option is utilize ECMAScript 5 immutable properties in the JavaScript library. Another option provided by Gaz (Gareth) was to use a specific code construct to limit mutability with anonymous closures. An example follows: ```javascript function escapeHTML(str) { str = str + "''"; var out = "''"; for(var i=0; i') { out += '&gt;'; } else if(str[i] === "'") { out += '&#39;'; } else if(str[i] === '"') { out += '&quot;'; } else { out += str[i]; } } return out; } ``` GUIDELINE \#6 - Use untrusted data on only the right side of an expression Use untrusted data on only the right side of an expression, especially data that looks like code and may be passed to the application (e.g., `location` and `eval()`). ```javascript window[userDataOnLeftSide] = "userDataOnRightSide"; ``` Using untrusted user data on the left side of the expression allows an attacker to subvert internal and external attributes of the window object, whereas using user input on the right side of the expression doesn't allow direct manipulation. GUIDELINE \#7 - When URL encoding in DOM be aware of character set issues When URL encoding in DOM be aware of character set issues as the character set in JavaScript DOM is not clearly defined (Mike Samuel). GUIDELINE \#8 - Limit access to object properties when using object\[x\] accessors Limit access to object properties when using `object[x]` accessors (Mike Samuel). In other words, add a level of indirection between untrusted input and specified object properties. Here is an example of the problem using map types: ```javascript var myMapType = {}; myMapType[] = "moreUntrustedData"; ``` The developer writing the code above was trying to add additional keyed elements to the `myMapType` object. However, this could be used by an attacker to subvert internal and external attributes of the `myMapType` object. A better approach would be to use the following: ```javascript if (untrustedData === 'location') { myMapType.location = "moreUntrustedData"; } ``` GUIDELINE \#9 - Keep HTML sanitization separate from JavaScript execution Use an HTML sanitizer such as DOMPurify when the application must render untrusted markup; see the HTML sanitization guidance. HTML sanitizers filter markup and do not provide a sandbox for executing arbitrary JavaScript. Do not pass untrusted code to `eval()` or `Function()`. GUIDELINE \#10 - Don't eval() JSON to convert it to native JavaScript objects Don't `eval()` JSON to convert it to native JavaScript objects. Use the built-in `JSON.parse()` to deserialize JSON into JavaScript values, and `JSON.stringify()` to serialize JavaScript values into JSON. `JSON.parse()` rejects anything that is not valid JSON, so it cannot execute attacker-supplied code the way `eval()` can. > [!WARNING] > `JSON.stringify()` is not an output-encoding function. Its output is valid JSON, but embedding it in HTML requires protection for the destination context. Prefer a separate response with `Content-Type: application/json`, parsed client-side with `JSON.parse()`. If JSON must be embedded in an inline script, use a serializer or encoder documented for that exact placement, protecting both JavaScript syntax and the enclosing HTML script context, including literal `</script` sequences. HTML entity encoding or JavaScript quote escaping alone is not sufficient for this placement. For other placements, follow the context-specific XSS encoding rules.

Complex Contexts In many cases the context isn't always straightforward to discern. ```html ', 'test');">Click Me ... Function myFunction (url,name) { window.location = url; } ``` In the above example, untrusted data started in the rendering URL context (`href` attribute of an `a` tag) then changed to a JavaScript execution context (`javascript:` protocol handler) which passed the untrusted data to an execution URL subcontext (`window.location` of `myFunction`). Because the data was introduced in JavaScript code and passed to a URL subcontext the appropriate server-side encoding would be the following: ```html ', 'test');"> Click Me ... ``` Or if you were using ECMAScript 5 with an immutable JavaScript client-side encoding libraries you could do the following: ```html ', 'test');">Click Me ... Function myFunction (url,name) { var encodedURL = ESAPI.encoder().encodeForURL(url); //URL encoding using client-side scripts window.location = encodedURL; } ``` Inconsistencies of Encoding Libraries There are a number of open source encoding libraries out there: 1. OWASP ESAPI 2. OWASP Java Encoder 3. Apache Commons Text StringEscapeUtils, replace one from Apache Commons Lang3 4. Jtidy 5. Your company's custom implementation. Some work on a denylist while others ignore important characters like "&lt;" and "&gt;". Java Encoder is an active project providing supports for HTML, CSS and JavaScript encoding. ESAPI is one of the few which works on an allowlist and encodes all non-alphanumeric characters. It is important to use an encoding library that understands which characters can be used to exploit vulnerabilities in their respective contexts. Misconceptions abound related to the proper encoding that is required. Encoding Misconceptions Many security training curriculums and papers advocate the blind usage of HTML encoding to resolve XSS. This logically seems to be prudent advice as the JavaScript parser does not understand HTML encoding. However, if the pages returned from your web application utilize a content type of `text/xhtml` or the file type extension of `*.xhtml` then HTML encoding may not work to mitigate against XSS. For example: ```html &#x61;lert(1); ``` The HTML encoded value above is still executable. If that isn't enough to keep in mind, you have to remember that encodings are lost when you retrieve them using the value attribute of a DOM element. Let's look at the sample page and script: ```html "> ... var x = document.myForm.lName.value; //when the value is retrieved the encoding is reversed document.writeln(x); //any code passed into lName is now executable. ``` Finally there is the problem that certain methods in JavaScript which are usually safe can be unsafe in certain contexts. Usually Safe Methods One example of an attribute which is thought to be safe is `innerText`. Some papers or guides advocate its use as an alternative to `innerHTML` to mitigate against XSS in `innerHTML`. However, depending on the tag which `innerText` is applied, code can be executed. ```html var tag = document.createElement("script"); tag.innerText = ""; //executes code ``` The `innerText` feature was originally introduced by Internet Explorer, and was formally specified in the HTML standard in 2016 after being adopted by all major browser vendors. Detect DOM XSS using variant analysis Vulnerable code: ``` var x = location.hash.split("#")[1]; document.write(x); ``` Semgrep rule to identify above dom xss link.

• MDN: innerHTML Security Considerations • DOMPurify: HTML Sanitization