the-web-application-hackers-handbook

456 Chapter 12 n Attacking Users: Cross-Site Scripting
If this happens, do not give up! Your next task is to determine what serverside
processing is occurring that is affecting your input. There are three broad
possibilities:
n The application (or a web application firewall protecting the application)
has identified an attack signature and has blocked your input.
n The application has accepted your input but has performed some kind of
sanitization or encoding on the attack string.
n The application has truncated your attack string to a fixed maximum length.
We will look at each scenario in turn and discuss various ways in which the
obstacles presented by the application’s processing can be bypassed.
Beating Signature-Based Filters
In the first type of filter, the application typically responds to your attack string
with an entirely different response than it did for the harmless string. For
example, it might respond with an error message, possibly even stating that a
possible XSS attack was detected, as shown in Figure 12-8.
Figure 12-8: An error message generated by ASP.NET’s anti-XSS filters
If this occurs, the next step is to determine what characters or expressions
within your input are triggering the filter. An effective approach is to remove
different parts of your string in turn and see whether the input is still being
blocked. Typically, this process establishes fairly quickly that a specific expression
such as is causing the request to be blocked. You then need to
test the filter to establish whether any bypasses exist.
There are so many different ways to introduce script code into HTML pages
that signature-based filters normally can be bypassed. You can find an alternative