DOM-based XSS/nan

Iú-kuan Khiā-tī DOM ê XSS
DOM-based XSS (or type-0 XSS) is a type of attack that occurs when client-side scripts (such as JavaScript) manipulate the page's DOM, allowing an attacker to run JavaScript in the victim's browser.

This class of XSS is distinct from Reflective XSS (type-1 XSS) and Stored XSS (type-2 XSS), since the server is not returning executable JavaScript to the browser. Instead, data that has been sanitized by the server, or possibly never sent to the server, is converted to executable JavaScript by the existing code running on the page.

For example, consider this example script from the OWASP website:

... Suán-ti̍k lí-ê gí-giân: document.write(""+document.location.href.substring(document.location.href.indexOf("default=")+8)+""); document.write("English"); ...

If the page is loaded with the 'default' parameter set to ' alert("xss") ' instead of the intended language string, then the extra script will be added into the page's DOM and executed as the page is loaded.

Ī-hông
Although JavaScript can be added to MediaWiki sites without a formal code review process, these scripts can put other users in danger if they don't prevent these attacks.

As with standard XSS prevention, you should validate the data coming in when possible, and always escape the data as your script writes out to the page. In order to do this escaping, you should avoid using some methods that make escaping difficult, and instead use methods that make separation of HTML structure and values or text easy.

It can be tempting to use data attributes to provide information for javascript. This is generally good practice, but remember that users are allowed to make elements with arbitrary data attributes too, so any information taken from a data attribute (e.g. using jQuery's ) should be treated as untrusted input and validated.

Phiah-bián
In general, these functions should be avoided if possible. They can be made secure, but require an understanding of how each browser's JavaScript engine works to make sure that all XSS vectors have been mitigated.

Element ê  hām   hong-huat

JQuery's  method (which uses .innerHTML)

Using user data in jQuery's element creation

jQuery's append method, when you are not certain of the type and value of every node or object you are appending. If it is a string of (apparent) HTML, jQuery will implicitly convert it to an element.

hi̍k-tsiá

Using user data in a string passed to,  , an object's event handler, or   url targets

Using user data in strings that generate CSS

Sú-iōng
When updating the page's DOM, you should typically use this pattern of functions for creating DOM elements and inserting them into the DOM:

As shown, you can use  to create the element, and any attributes that do not include user-controlled data. You can also use  to set the element's attributes.

When you have a correctly constructed element, you can use  or   to insert the element into the DOM. But see above; do not use append or appendTo if you do not know exactly what you are appending.

The  method can be used to set the text body of an element, and will correctly escape any HTML.

If you're not using jQuery, you can use

Because the JavaScript is able to clearly interpret what strings are meant to represent element names, attribute names, and attribute values, it will correctly escape any HTML characters that may have been inserted into user-controlled data.

Siau-to̍k
There may be times when you will need to mix user-controlled data with HTML. In those cases, you will need to ensure that the user-controlled data is properly escaped for the HTML context where it is being inserted.

For example, inserting data into the text of a div element:

Requires different escaping than if you insert that user-controlled data into the id attribute of the div element.

A list of contexts and escaping rules can be found in the OWASP XSS Prevention Cheat Sheet

For the most simple case (inserting user-controlled data into the text of an element), you can use jQuery's  method or.