DOM Based Cross Site Scripting

Xss is very popular now. in addition, xss tools are everywhere. As a result, just like sqlinj, many websites are hard to find obvious xss bugs. In the past, we used to search for xss in black boxes, and the results were very obvious, for white boxes, it is generally based on Server languages such as [php/asp/jsp...] search for output statements of variables, such as print/echo .... and so on.

Today, let's take a look at Daniel Amit Klein's 2005 writing [DOM Based Cross Site Scripting or XSS of the Third Kind]: the http://www.webappsec.org/projects/articles/071105.html mentioned DOM's xss is harder to find than the ones mentioned above, as luoluo said, finding dom-based xss is king :)
To find this type of xss, we need to analyze the js Code. In this way, we can analyze js like some of the Server language vulnerabilities: the same vulnerabilities as php are generated: variable ---> output function, while js is a variable ---> output to the browser, we are looking for dom-xss to analyze the extraction and output statements of variables.

For example, the output of variables to some objects executed by the browser: document. write, eval... and so on.
Variable input/extraction: Some objects of the document, such as document. URL document. location..., etc.

Just like the ones listed in the Amit Klein article:

2. Analyzing and hardening the client side (Javascript) code. Reference to DOM objects that may be influenced by the user (attacker) shocould be inspected, including (but not limited ):

Document. URL
Document. URLUnencoded
Document. location (and attributes of its properties)
Document. referrer
Window. location (and parts of its properties)
Note that a document object property or a window object property may be referenced syntactically in gateways-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 shocould 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 varous browser extensions ):

Write raw HTML, e.g .:
Document. write (...)
Document. writeln (...)
Document. body. innerHtml =...
Directly modifying the DOM (including DHTML events), e.g .:
Document. forms [0]. action =... (And varous other collections)
Document. attachEvent (...)
Document. create... (...)
Document.exe cCommand (...)
Document. body .... (Accessing the DOM through the body object)
Window. attachEvent (...)
Replacing the document URL, e.g .:
Document. location =... (And assigning to location's href, host and hostname)
Document. location. hostname =...
Document. location. replace (...)
Document. location. assign (...)
Document. URL =...
Window. navigate (...)
Opening/modifying a window, e.g .:
Document. open (...)
Window. open (...)
Window. location. href =... (And assigning to location's href, host and hostname)
Directly executing script, e.g .:
Eval (...)
Window.exe cScript (...)
Window. setInterval (...)
Window. setTimeout (...)

Then we can analyze the dom-xss and directly analyze those js functions. How can we analyze them? Like PHP, we can use some static methods such as grep, what about dynamic methods? You can use proxy-based intermediate automatic fuzz, and hook of js functions proposed by luoluo... Look Forward To luoluo's fuzz-tool

In addition, when using or triggering dom-xss, you should note that a js feature is [js closed tag priority]: http://superhei.blogbus.com/logs/10073294.html.
Finally, I would like to thank luoluo for his patience and guidance, as well as jx for sharing his 0day :)