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

384

Chapter 12 

■

Attacking Other Users

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

---

First, in the case of reflected XSS, to exploit a vulnerability the attacker must

use some means of inducing victims to visit his crafted URL. In the case of

stored XSS, this requirement is avoided. Having deployed his attack within

the application, the attacker simply needs to wait for victims to browse to the

page or function that has been compromised. In general, this will be a regular

page of the application that normal users will access of their own accord. 

Second, the attacker’s objectives in exploiting an XSS bug are usually

achieved much more easily if the victim is using the application at the time of

the attack. For example, if the user has an existing session, this can be immedi-

ately hijacked. In a reflected XSS attack, the attacker may try to engineer this

situation by persuading the user to log in and then click on a link that he sup-

plies, or he may attempt to deploy a persistent payload that waits until the

user logs in. However, in a stored XSS attack, it is usually guaranteed that vic-

tim users will be already accessing the application at the time that the attack

strikes. Because the attack payload is stored within a page of the application

that users access of their own accord, any victim of the attack will by definition

be using the application at the moment the payload executes. Further, if the

page concerned is within the authenticated area of the application, then any

victim of the attack must in addition be logged in at the time.

These differences between reflected and stored XSS mean that stored XSS

flaws are often critical to an application’s security. In most cases, an attacker

can submit some crafted data to the application and then wait for victims to be

hit. If one of those victims is an administrator, then the attacker will have com-

promised the entire application.