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

Beating Sanitization

Of all the obstacles that you may encounter when attempting to exploit poten-

tial XSS conditions, this is probably the most common. Here, the application

performs some kind of sanitization or encoding on your attack string which

renders it harmless, preventing it from causing the execution of JavaScript.

The most prevalent manifestation of data sanitization occurs when the

application HTML-encodes certain key characters that are necessary to deliver

an attack (so 

<

becomes 

<

and 

>

becomes 

>

). In other cases, the applica-

tion may remove altogether certain characters or expressions, in an attempt to

cleanse your input of malicious content.

When this defense is encountered, the first step is to determine precisely

which characters and expressions are being sanitized, and whether it is still

possible to carry out an attack with the remaining characters. For example, if

your data is being inserted directly into an existing script, you may not need to

employ any HTML tag characters. If it appears impossible to perform an attack

without using input that is being sanitized, then you need to test the effective-

ness of the sanitizing filter to establish whether any bypasses exist. Here are

some examples of common bypasses:

■■

If the filter removes certain expressions altogether, and at least one of

the removed expressions is more than one character in length, then it

may be possible to smuggle that expression past the filter, provided that

the sanitization is not applied recursively. For example:

ipt>

■■

As previously described for signature-based filters, it may be possible

to bypass a sanitizing filter by encoding filtered expressions or by

inserting a null byte before them.