an actual script to be run by the browser. However, there are ways around those sorts
of limited input checks.
Persistent Cross-Site Scripting
Persistent cross-site scripting is also sometimes known as
stored
cross-site scripting
. Similarly, reflected cross-site scripting is some‐
times known as
nonpersistent cross-site scripting
.
The other type of cross-site scripting attack is called
reflected cross-site scripting
.
Instead of being stored on a server for someone to come visit later, this type requires
that the script be part of a URL that is then sent to users. This sort of attack looks the
same, in essence, as persistent in the sense that you would still need to generate a
script that can be run in the browser. The reflected attack requires a couple of other
things, though. First, certain characters aren’t allowed as part of a URL. This requires
that some of the characters be URL encoded.
The process of URL encoding is simple. Any character can be rendered this way, but
some are required to be encoded. The space, for example, can’t be part of a URL
because the browser would consider the URL complete when it hit the space and
wouldn’t consider anything beyond that. To URL encode, you need to look up the
ASCII value for the character and convert the decimal value to hexadecimal, as neces‐
sary. Once you have done that, you add a % (percent) to the beginning of the value
and you have a character that has been URL encoded. A space, for example, is ren‐
dered as %20. The hexadecimal value 20 is 32 in decimal (16 × 2), and that is the
ASCII value for the space character. Any character in the ASCII table can be con‐
verted in this way.
The second thing that should probably happen is that the URL should be hidden or
obscured in some way. This could be done by anchoring text to the link in an e-mail.
After all, if you were to receive an email with this in it, you probably wouldn’t click it:
http://www.rogue.com/somescript.php?%3Cscript%3Ealert(%22hi%20there!%22)%3B
%3C%2Fscript%3E
.
The target, as noted earlier, is the client that is connecting to the website. The script
could do any number of things, including retrieving data from the client and sending
it off to an attacker. Anything that the browser can access could be handled or manip‐
ulated. This creates a threat to the user, rather than a threat to the organization or its
infrastructure. The website at the organization is just the delivery mechanism because
of an application or script that does a poor job of input validation.
