The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

Be sure to include scripts that appear in static HTML pages as well as

dynamically generated pages — DOM-based XSS bugs may exist in any location

where client-side scripts are used, regardless of the type of page or whether

you see parameters being submitted to the page.

In every instance where one of the preceding APIs is being used, closely

review the code to identify what is being done with the user-controllable data,

and whether crafted input could be used to cause execution of arbitrary

JavaScript. In particular, review and test any instance where your data is being

passed to any of the following APIs:

■

document.write() 

■

document.writeln() 

■

document.body.innerHtml

■

eval()

■

window.execScript()

■

window.setInterval()

■

window.setTimeout()

As with reflected and stored XSS, you may find that the application imple-

ments filters that block requests containing certain malicious strings. Even

though the vulnerable operation occurs on the client, and the server does not

70779c12.qxd:WileyRed  9/14/07  3:14 PM  Page 418

---

return the user-supplied data in its response, the URL is still submitted to the

server, and so the application may validate the data and fail to return the vul-

nerable client-side script when a malicious payload is detected.

If this defense is encountered, you should attempt each of the potential fil-

ter bypasses that were described previously for reflected XSS vulnerabilities,

to test the robustness of the server’s validation. In addition to these attacks,

there are several techniques unique to DOM-based XSS bugs that may enable

your attack payload to evade server-side validation.

When client-side scripts extract a parameter’s value from the URL, they

very rarely parse the query string properly into name/value pairs. Instead,

they typically search the URL for the parameter name followed by the 

=

sign,

and then extract whatever comes next, up until the end of the URL. This

behavior can be exploited in two ways:

■■

If the server’s validation logic is being applied on a per-parameter

basis, rather than on the entire URL, then the payload can be placed

into an invented parameter appended after the vulnerable parameter.

For example:

https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred&

foo=

Here, the invented parameter is ignored by the server and so is not sub-

ject to any filtering. However, because the client-side script searches the

query string for 

message=

and extracts everything following this, it will

include your payload in the string which it processes.

■■

If the server’s validation logic is being applied to the entire URL, and

not just to the message parameter, it may still be possible to evade the

filter by placing the payload to the right of the HTML fragment charac-

ter 

#

. For example:

https://wahh-app.com/error.php?message=Sorry%2c+an+error+

occurred#

Here, the fragment string is still part of the URL, and so is stored in the

DOM and will be processed by the vulnerable client-side script. How-

ever, because browsers do not submit the fragment portion of the URL

to the server, the attack string will not even be sent to the server, and so

cannot be blocked by any kind of server-side filter. Because the client-

side script extracts everything after 

message=

, the payload is still copied

into the HTML page source.