There are a number of techniques we can use in order to fit more characters in XSS vulnerable fields than the maximum allowed. In this section, we are going to play with fragment identifiers and XSS payloads in order to circumvent maximum field length restrictions and also bypass intrusion detection and preventing systems.

First of all, let's examine a hypothetical XSS vulnerability, which is defined like this:

http://www.acme.com/path/to/search.asp?query=">[payload]

Look carefully at the part near the [payload]. The first two characters of the query parameter close any open element attribute and the element body, which is followed by the payload. In order to exploit the vulnerability, we can do something as simple as this:

http://www.acme.com/path/to/search.asp?query=">

This is enough to prove that the application is vulnerable to XSS, but will it be enough if we want to create a proper exploit? That might not be the case. The hypothetical application sanitizes the length of the query parameter in a way that only 60 characters are allowed. Obviously, our injection is highly limited if we only have tha number of characters.

Granted, we are still able to perform injection of a remote script via:

http://www.acme.com/path/to/search.asp?query=">#alert('xss')

Let's examine the exploit. First of all, the value of the query field is within the restrictions of the application: our code is only 48 characters. Notice that in the place of the [pay-load] we have < script> eval(location.hash.substr(1))script>, which calls the JavaScript eval function on the hash parameter.