As the use of the Internet has grown, so has the number of attacks which attempt to use it for nefarious purposes. One vulnerability which has become commonly exploited is known as cross-site scripting (XSS). An attack on this class of vulnerabilities occurs when an attacker injects malicious code into a web application in an attempt to gain access to unauthorized information. In such instances, the victim is unaware that their information is being transferred from a site that he/she trusts to another site controlled by the attacker. In this report, we will examine the types of cross-site scripting vulnerabilities. Type 0 vulnerabilities are caused by poorly-written client-side scripts, while Type 1 and Type 2 vulnerabilities reside on the server. The difference between Types 1 and 2 is the length of time that the malicious script is stored. Type 1 vulnerabilities use attack code immediately while Type 2 vulnerabilities store the code on the server for future victims. We present an example of a Type 2 vulnerability using a message board application and explain how it can be exploited. We then discuss how the lessons learned from this contrived demonstration can be applied to the Internet at large.
2. Types of Cross-site Scripting
These scripting languages allow users to exchange a multitude of information with web servers, and this information is often sensitive. There are several policies and mechanisms in place to safeguard such information, including the same-origin policy. This is a security measure within web browsers which prevents an object loaded from one “origin” from interacting with objects loaded from a different origin. Here, origin refers to the domain, protocol, and port associated with the object.
However, a clever attacker can find ways of getting around such security measures. The security of the web application depends not only on the web browser, but also on the web server. An attacker may exploit a bug in the web browser or web server, or vulnerability in the particular web application. The web server software and web browser software may be functioning properly, but the scripts used to set up the web application may present vulnerability. The attacker may then gain access to unauthorized content, including session cookies. Such attacks may include phishing, where the attacker fraudulently acquires sensitive information while posing as a trustworthy party, or browser exploits, where the injected code causes the browser to perform an unexpected action.
As the name suggests, cross-site scripting attacks work by using scripting capabilities to move data between different websites, usually unbeknownst to the victim. The attacker injects the code into the victim’s web browser in a way that is not immediately apparent. This can be done when the user simply clicks a link or views a webpage. When the action is taken, a script runs in the web browser which can allow the attacker to perform almost any action. The exploited vulnerabilities are classified into three types, which are discussed in the following subsections. The differences are based on the location of the vulnerability, and how long the malicious code is stored.
2.1 Type 0: DOM-based XSS
A typical attack on this type of vulnerability involves the use of pages on the user’s local file system. This allows the remote script to run with privileges on the user’s system. This is also an example of a cross-zone scripting attack, where the exploit takes advantage of vulnerability in a zone-based security solution.
Mallory sends a URL to Alice (via e-mail or another mechanism) of a maliciously constructed web page.
Alice clicks on the link.
Mallory’s malicious script now may run commands with the privileges Alice holds on her own computer.
2.2 Type 1: Reflected or Non-Persistent XSS
The next type of vulnerability is the most common type of XSS vulnerability. It is sometimes referred to as a reflected or non-persistent vulnerability. This occurs when data provided by a web client is immediately used by scripts on the server to generate results which are displayed to the user, as is commonly seen with search engines. If the user-supplied data is not validated, some of the results could include a client-side script that is executed in the browser instead of HTML.
While this is a common vulnerability, it often requires social engineering in order to be exploited since the malicious code is supplied by the user.
Alice often visits a particular website, which is hosted by Bob. Bob’s website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.
Mallory observes that Bob’s website contains a reflected XSS vulnerability.
Mallory crafts a URL to exploit the vulnerability, and sends Alice an e-mail, making it look as if it came from Bob (i.e., the e-mail is spoofed).
Alice visits the URL provided by Mallory while logged into Bob’s website.
The malicious script embedded in the URL executes in Alice’s browser, as if it came directly from Bob’s server. The script steals sensitive information (authentication credentials, billing info, etc.) and sends this to Mallory’s web server without Alice’s knowledge.
2.3 Type 2: Stored XSS
The last type of vulnerability allows the most powerful attacks, though these attacks may arguably be the easiest to deploy. Known as the persistent, stored, or second-order XSS vulnerability, it occurs when user-provided data is stored on a web server and then later displayed to other users without being encoded using HTML entities. This can be found on message boards or online social networking sites, where users are allowed to post HTML-formatted messages for others to see. As such, this does not require the same extent of social engineering as the Type 0 and Type 1 attacks
Bob hosts a web site which allows users to post messages and other content to the site for later viewing by other members.
Mallory notices that Bob’s website is vulnerable to a Type 2 XSS attack.
Mallory posts a message, controversial in nature, which may encourage many other users of the site to view it.
Upon merely viewing the posted message, site users’ session cookies or other credentials could be taken and sent to Mallory’s web server without their knowledge.
Later, Mallory logs in as other site users and posts messages on their behalf.