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

When probing for reflected XSS, it is trivial to identify which request

parameters are potentially vulnerable, by testing one parameter at a time and

reviewing each response for any appearance of your input. With stored XSS,

however, this may be less straightforward. If you submit the same test string as

every parameter to every page, then you may find this string reappearing at

multiple locations within the application, and it may not be clear from the

context precisely which parameter is responsible for the appearance. To avoid

this problem, you can submit a different test string as every parameter when

probing for stored XSS flaws — for example, by concatenating your unique

string with the name of the field it is being submitted to.

Finding and Exploiting DOM-Based XSS Vulnerabilities

DOM-based XSS vulnerabilities cannot be identified by submitting a unique

string as each parameter and monitoring responses for the appearance of that

string.

One basic method for identifying DOM-based XSS bugs is to manually walk

through the application with your browser, and modify each URL parameter

to contain a standard test string such as the following:

“

By actually displaying each returned page in your browser, you will cause

all client-side scripts to execute, referencing your modified URL parameter

where applicable. Any time a dialog box appears containing your cookies, you

will have found a vulnerability (which may be either DOM-based or standard

reflected XSS). This process could even be automated by a tool which imple-

mented its own JavaScript interpreter.

However, this basic approach will not identify all DOM-based XSS bugs. As

you have already seen, the precise syntax required to inject valid JavaScript

into an HTML document depends upon the syntax that already appears before

and after the point where the user-controllable string gets inserted. It may be

necessary to terminate a single- or double-quoted string or to close specific

tags. Sometimes, new tags may be required, but sometimes not. The applica-

tion may modify your input in various ways and yet may still be vulnerable.

If the standard test string does not happen to result in valid syntax when it

is processed and inserted, then the embedded JavaScript will not execute and

so no dialog will appear, even though the application may be vulnerable to a