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

Finding and Exploiting XSS Vulnerabilities

A basic approach to identifying XSS vulnerabilities is to use a standard proof-

of-concept attack string such as the following:

“>

This string is submitted as every parameter to every page of the application,

and responses are monitored for the appearance of this same string. If cases are

found where the attack string appears unmodified within the response, then

the application is almost certainly vulnerable to XSS.

If your intention is simply to identify some instance of XSS within the applica-

tion as quickly as possible in order to launch an attack against other app lication

users, then this basic approach is probably the most effective, because it can be

highly automated and produces minimal false positives. However, if your objec-

tive is to perform a comprehensive test of the application, designed to locate as

many individual vulnerabilities as possible, then the basic approach needs to be

supplemented with more sophisticated techniques. There are several different

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

---

ways in which XSS vulnerabilities may exist within an application that will not

be identified via the basic approach to detection:

■■

Many applications implement rudimentary blacklist-based filters in an

attempt to prevent XSS attacks. These filters typically look for expres-

sions like 

“>

“%3e%3cscript%3ealert(document.cookie)%3c/script%3e

“>ipt>alert(document.cookie)ipt>

%00”>

Note that in some of these cases, the input string may be sanitized, decoded,

or otherwise modified before being returned in the server’s response, and yet

might still be sufficient for an XSS exploit. In this situation, no detection

approach based upon submitting a specific string and checking for its appear-

ance in the server’s response will in itself succeed in finding the vulnerability.

In exploits of DOM-based XSS vulnerabilities, the attack payload is not nec-

essarily returned in the server’s response but is retained in the browser DOM

and accessed from there by client-side JavaScript. Again, in this situation, no

approach based upon submitting a specific string and checking for its appear-

ance in the server’s response will succeed in finding the vulnerability.