the-web-application-hackers-handbook

Chapter 13 n Attacking Users: Other Techniques 511
n In some applications, anti-CSRF tokens are tied only to the current user,
and not to his session. In this situation, if the login form is not protected
against CSRF, a multistage exploit may still be possible. First, the attacker
logs in to his own account to obtain a valid anti-CSRF token that is tied
to his user identity. He then uses CSRF against the login form to force
the victim user to log in using the attacker’s credentials, as was already
described for the exploitation of same-user stored XSS vulnerabilities.
Once the user is logged in as the attacker, the attacker uses CSRF to cause
the user to issue a request exploiting the XSS bug, using the anti-CSRF
token previously acquired by the attacker. The attacker’s XSS payload
then executes in the user’s browser. Since the user is still logged in as the
attacker, the XSS payload may need to log the user out again and induce
the user to log back in, with the result that the user’s login credentials
and resulting application session are fully compromised.
n If anti-CSRF tokens are tied not to the user but to the current session,
a variation on the preceding attack may be possible if any methods are
available for the attacker to inject cookies into the user’s browser (as
described later in this chapter). Instead of using a CSRF attack against
the login form with the attacker’s own credentials, the attacker can
directly feed to the user both his current session token and the anti-
CSRF token that is tied to it. The remainder of the attack then proceeds
as previously described.
These scenarios aside, robust defenses against CSRF attacks do in many situations
make it considerably harder, if not impossible, to exploit some reflected XSS
vulnerabilities. However, it goes without saying that any XSS conditions in an
application should always be fixed, regardless of any anti-CSRF protections in place
that may, in some situations, frustrate an attacker who is seeking to exploit them.
UI Redress
Fundamentally, anti-CSRF defenses involving tokens within the page aim to
ensure that requests made by a user originate from that user’s actions within the
application itself and are not induced by some third-party domain. UI redress
attacks are designed to allow a third-party site to induce user actions on another
domain even if anti-CSRF tokens are being used. These attacks work because,
in the relevant sense, the resulting requests actually do originate within the
application being targeted. UI redress techniques are also often referred to as
“clickjacking,” “strokejacking,” and other buzzwords.
In its basic form, a UI redress attack involves the attacker’s web page loading
the target application within an iframe on the attacker’s page. In effect,
the attacker overlays the target application’s interface with a different interface