the-web-application-hackers-handbook

446 Chapter 12 n Attacking Users: Cross-Site Scripting
An alternative to session hijacking, where an attacker simply wants to carry
out a specific set of actions on behalf of each compromised user, is to use the
attack payload script itself to perform the actions. This attack payload is particularly
useful in cases where an attacker wants to perform some action that
requires administrative privileges, such as modifying the permissions assigned
to an account he controls. With a large user base, it would be laborious to hijack
each user’s session and establish whether the victim was an administrator. A
more effective approach is to induce every compromised user to attempt to
upgrade the permissions on the attacker’s account. Most attempts will fail, but
the moment an administrative user is compromised, the attacker succeeds in
escalating privileges. Ways of inducing actions on behalf of other users are
described in the “Request Forgery” section of Chapter 13.
The MySpace XSS worm described earlier is an example of this attack payload.
It illustrates the power of such an attack to perform unauthorized actions on
behalf of a mass user base with minimal effort by the attacker. This attack used
a complex series of requests using Ajax techniques (described in Chapter 3) to
carry out the various actions that were required to allow the worm to propagate.
An attacker whose primary target is the application itself, but who wants
to remain as stealthy as possible, can leverage this type of XSS attack payload
to cause other users to carry out malicious actions of his choosing against the
application. For example, the attacker could cause another user to exploit a SQL
injection vulnerability to add a new administrator to the table of user accounts
within the database. The attacker would control the new account, but any investigation
of application logs may conclude that a different user was responsible.
Exploiting Any Trust Relationships
You have already seen one important trust relationship that XSS may exploit:
browsers trust JavaScript received from a website with the cookies issued by
that website. Several other trust relationships can sometimes be exploited in
an XSS attack:
n If the application employs forms with autocomplete enabled, JavaScript
issued by the application can capture any previously entered data that
the user’s browser has stored in the autocomplete cache. By instantiating
the relevant form, waiting for the browser to autocomplete its contents,
and then querying the form field values, the script may be able to steal
this data and transmit it to the attacker’s server. This attack can be more
powerful than injecting Trojan functionality, because sensitive data can
be captured without requiring any interaction from the user.
n Some web applications recommend or require that users add their domain
name to their browser’s “Trusted Sites” zone. This is almost always undesirable
and means that any XSS-type flaw can be exploited to perform