the-web-application-hackers-handbook

438 Chapter 12 n Attacking Users: Cross-Site Scripting
JavaScript contained within or loaded by a page returned by that domain only.
Hence, if a script residing on mdattacker.net queries document.cookie, it will
not obtain the cookies issued by mdsec.net, and the hijacking attack will fail.
The reason why the attack that exploits the XSS vulnerability is successful is
that, as far as the user’s browser is concerned, the attacker’s malicious JavaScript
was sent to it by mdsec.net. When the user requests the attacker’s URL, the
browser makes a request to http://mdsec.net/error/5/Error.ashx , and the
application returns a page containing some JavaScript. As with any JavaScript
received from mdsec.net, the browser executes this script within the security
context of the user’s relationship with mdsec.net. This is why the attacker’s
script, although it actually originates elsewhere, can gain access to the cookies
issued by mdsec.net. This is also why the vulnerability itself has become
known as cross-site scripting.
Stored XSS Vulnerabilities
A different category of XSS vulnerability is often called stored cross-site scripting.
This version arises when data submitted by one user is stored in the application
(typically in a back-end database) and then is displayed to other users without
being filtered or sanitized appropriately.
Stored XSS vulnerabilities are common in applications that support interaction
between end users, or where administrative staff access user records and
data within the same application. For example, consider an auction application
that allows buyers to post questions about specific items and sellers to post
responses. If a user can post a question containing embedded JavaScript, and
the application does not filter or sanitize this, an attacker can post a crafted
question that causes arbitrary scripts to execute within the browser of anyone
who views the question, including both the seller and other potential buyers.
In this context, the attacker could potentially cause unwitting users to bid on
an item without intending to, or cause a seller to close an auction and accept
the attacker’s low bid for an item.
Attacks against stored XSS vulnerabilities typically involve at least two requests
to the application. In the first, the attacker posts some crafted data containing
malicious code that the application stores. In the second, a victim views a page
containing the attacker’s data, and the malicious code is executed when the
script is executed in the victim’s browser. For this reason, the vulnerability is
also sometimes called second-order cross-site scripting. (In this instance, “XSS”
is really a misnomer, because the attack has no cross-site element. The name is
widely used, however, so we will retain it here.)
Figure 12-4 illustrates how an attacker can exploit a stored XSS vulnerability
to perform the same session hijacking attack as was described for reflected XSS.