The Web Application Hacker’s Handbook Discovering and Exploiting Security Flaws

unauthenticated part of an application can normally be used to directly

compromise the sessions of authenticated users. Hence, an unauthenticated

reflected XSS flaw is typically more serious than an authenticated one, because

the scope of potential victims is wider. Second, even if a user is not yet

authenticated, an attacker can deploy some Trojan functionality which persists

in the victim’s browser across multiple requests, waiting until they log in, and

then hijacking the resulting session.

Chapter 12 

■

Attacking Other Users

393

70779c12.qxd:WileyRed  9/14/07  3:14 PM  Page 393

---

Inducing User Actions

If an attacker hijacks a victim’s session, then they can use the application “as”

that user, and carry out any action on their behalf. However, this approach to

performing arbitrary actions may not always be desirable. It requires that the

attacker monitor their own server for submissions of captured session tokens

from compromised users, and it requires them to carry out the relevant action

on behalf of each and every user. If many users are being attacked, this may

not be practicable. Further, it leaves a rather unsubtle trace in any application

logs, which could be trivially used to identify the computer responsible for the

unauthorized actions during any investigation.

An alternative to session hijacking, when 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 partic-

ularly useful in cases where an attacker wishes to perform some action which

requires administrative privileges, such as modifying the permissions assigned

to an account which he controls. With a large user base, it would be laborious to

hijack each user’s session and establish whether the victim was an administra-

tor. 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 will suc-

ceed in escalating privileges. Ways of inducing actions on behalf of other users

are described in the “Request Forgery” section, later in this chapter.

The MySpace XSS worm described earlier is an example of this attack pay-

load, and illustrates the power of such an attack to perform unauthorized

actions on behalf of a mass user base with minimal effort by the attacker. 

An attacker whose primary target is the application itself, but who wishes 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.