Cross-site scripting

Cross site scripting (XSS) is a type of computer security vulnerability typically found in web applications which can be used by an attacker to compromise browser access controls (sometimes called a sandbox) of client-side scripting languages.

Etymology

The term cross site scripting is not a very accurate description of this class of vulnerability. In the words of XSS pioneer Marc Slemko:

This issue isn't just about scripting, and there isn't necessarily anything cross site about it. So why the name? It was coined earlier on when the problem was less understood, and it stuck. Believe me, we have had more important things to do than think of a better name.

The acronym CSS was often used in the early days to refer to cross site scripting vulnerabilities, but this quickly became confusing in technical circles because both Cascading Style Sheets and the Content-Scrambling System shared the same acronym. Perhaps the first person use of the abreviation XSS was by Steve Champeon in his Webmonkey article XSS, Trust, and Barney. In 2002, Steve also posted the suggestion to use XSS as an alternative abreviation to the Bugtraq mailing list. In a rare show of unity, the security community quickly adopted the alternative, and CSS is rarely used today to refer to cross site scripting.

History

Background

When Netscape first introduced the JavaScript language, they realized the security risks of allowing a webserver to send executable code to a browser (even if only in a browser sandbox). One key issue with this is the case where users have more than one browser window open at once. In some instances, script from one page should be allowed to access data from another page or object, but in others, this should be strictly forbidden, as a malicious website could attempt to steal sensitive information this way. For this reason, the Same Origin Policy was introduced. Essentially this policy allows any interaction between objects and pages, so long as these objects come from the same domain and over the same protocol. That way, a malicious website wouldn't be able to access sensitive data in another browser window via JavaScript.

Since then, other similar access control policies have been adopted in other browsers and client-side scripting languages to protect users from malicious websites. In general, cross-site scripting holes can be seen as a vulnerabilities which allow attackers to bypass these mechanisms. By finding clever ways of injecting malicious script into pages served by other domains, an attacker can gain elevated privilege to sensitive page content, session cookies, and a variety of other objects.

Types

There are three distinct known types of XSS vulnerability to date. (These will be labeled Type 0, Type 1, and Type 2 for the purposes of this discussion, but these names are by no means industry standard nomenclature. Where possible, other names for these will be provided.)

Type 0

This form of XSS vulnerability has been referred to as DOM-based or Local cross site scripting, and while it isn't new by any means, a recent paper (DOM Based Cross Site Scripting) does a good job of defining its characteristics. With Type 0 cross site scripting vulnerabilities, the problem exists within a page's client-side script itself. For instance, if a piece of JavaScript accesses a URL request parameter and uses this information to write some HTML to it's own page, and this information isn't HTML quoted, a XSS hole will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.

In practice, exploiting such a hole would be very similar to the exploit of Type 1 vulnerabilities, except in one very important situation. Due to the way Internet Explorer treats client-side script in objects located in the local zone (for instance, on the client's local hard drive), a XSS hole of this kind in a local page can result in remote execution vulnerabilities. For example, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.

Type 1

This kind of cross site scripting hole is also referred to as a non-persistent or reflected vulnerability, and is by far the most common type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user supplied data is included in the resulting page without HTML quoting, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often result pages re-display the search string on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurances of the search terms aren't HTML quoted, a XSS hole will result.

At first blush, this doesn't appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in Type 0 vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross site scripting vulnerabilities.

Type 2

This type of XSS vulnerability is also referred to as a stored or persistent or second-order vulnerability, and it allows the most powerful kinds of attacks. A type 2 XSS vulnerability exists when data provided to an web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being HTML quoted. A classic example of this is with online message boards, where users are allowed to post HTML formatted messages for other users to read. These vulnerabilities are usually more significant than other types because an attacker can inject script just once, and could potentially hit a large number of other users with little need for social engineering. The methods of injection can vary a great deal, and an attacker may not need use the web application itself to exploit such a hole. Any data received by the web application (via email, system logs, etc) that can be controlled by an attacker must be quoted prior to re-display in a dynamic page, else a XSS vulnerability of this type could result.

Methods of Exploit

A classic example of cross site scripting is to supply parameters to a CGI script on a web site which cause the web site to emit bogus data. For example, the use of HTML client-side scripting language fragments in a web page parameter may insert this information into the rendered page, resulting in targeted web browsers executing the code.

This may be done by entering data into a web form on the site, for example as part of a bulletin board feature, or by publicly posting a URL which users are likely to click on, for example in e-mails or Usenet. Such a vulnerability in a web application can make phishing schemes more effective.

Note that despite the name, as example 2 demonstrates, this type of attack does not require the use of scripts.

Example 1:

UserA trusts example.com to run JavaScript on his machine.
UserB has found a way to inject/insert his/her own JavaScript code into example.com (for example into a bulletin board message) and inserts a malicious script that asks for people's credit card numbers and stores them somewhere where UserB can access them.
UserA visits example.com and UserB's script asks for his/her credit card number. Thinking that this is a legitimate request from example.com, UserA blissfully provides his/her credit card number.
UserB has effectively "stolen" UserA's credit card number using cross-site scripting and some social engineering.

Example 2:

UserA has an account at example.com and is logged in.
UserB injected a piece of JavaScript to retrieve the session ID of the current user and send it to him/her.
UserA visits the manipulated page and his/her session ID is transmitted to UserB.
UserB can now use UserA's account until he/she logs out (possibly longer if he/she changes UserA's password).

If UserB had put the code on his own website, it would not be allowed to access the session-cookie.

Real World Examples

There are literally hundreds of examples of cross site scripting vulnerabilities available publically. Just a few examples to illustrate the different types of holes will be listed here.

An example of a type 0 vulnerability was once found in an error page produced by bugzilla where JavaScript was used to write the current URL, through the document.location variable, to the page without any filtering or quoting. In this case, an attacker who controlled the URL might have been able to inject script, depending on the behavior of the browser in use. This vulnerability was fixed by encoding the special characters in the document.location string prior to writing it to the page.

A recent type 1 vulnerability can be found in older versions of ATutor, a Open Source Web-based Learning Content Management System (LCMS) written in PHP. This vulnerability exists in the application's site search page. Script could be injected into nearly every URL request parameter, and the result page would include the malicious script unquoted.

Finally, an example of a type 2 vulnerability was found in Hotmail, in October of 2001 by Marc Slemko, which allowed an attacker to steal a user's Microsoft .NET Passport session cookies. This exploit for this vulnerability consisted of sending a malicious email to a Hotmail user, which contained malformed HTML. The script filtering code in Hotmail's site failed to remove the broken HTML, but Internet Explorer's parsing algorithm happily interpreted the malicious code. This problem was quickly fixed, but multiple similar problems were found in Hotmail and other Passport sites later on.

Methods of Avoidance

Reliable avoidance of cross site scripting vulnerabilities currently requires the encoding of all HTML special characters in potentially malicious data. This is generally done right before display by web applications (or client-side script), and many programming languages have build-in functions or libraries which provide this encoding (in this context, also called quoting).

An example of this kind of quoting is shown below, from within the Python interpreter:

~> python
Python 2.3.5 (#2, Aug 30 2005, 15:50:26) 
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi

>>> print "<script>alert('xss');</script>"
<script>alert('xss');</script>

>>> print cgi.escape("<script>alert('xss');</script>");
&lt;script&gt;alert('xss');&lt;/script&gt;

Here, the first print statement produces executable client-side script, whereas the second print statement outputs a string which is an HTML-quoted version of the original script. The quoted versions of these characters will appear as literals in a browser, rather than with their special meaning as HTML tags. This prevents any script from being injected into HTML output, but it also prevents any user-supplied input from being formatted with benign HTML.

If one were to implement a function like cgi.escape() (which comes with Python), one would be best off converting all but known-safe characters to their equivalent HTML entity. Because browsers implement complex (and often buggy) parsing algorithms for HTML (in all of its flavors), it is difficult to predict what characters could be treated as special. In particular, support for Unicode character sets by browsers could leave an application open to XSS attacks if the HTML quoting algorithms only look for known-bad characters.

As stated above, the unfortunate consequence of this fix prevents users from being able to embed non-malicious HTML into pages. Because HTML standards do not provide any simple mechanism to disable client-side scripts in specific portions of a web-page, it is impossible to reliably cleanse script from normal HTML. In order to acheive HTML-like formatting of untrusted user content, many applications implement their own custom markup languages which are converted to HTML on the server-side before display.

Other Forms of Mitigation

Related Vulnerabilities

There are several classes of vulnerabilities or attack techniques which are related, and worth mentioning:

HTTP Header Injection vulnerabilities, which can be used to create Cross Site Scripting conditions in addition to allowing attacks such as HTTP Response Splitting
Cross Site Tracing attacks, which exploits the HTTP TRACE method to glean more information from a user's browser when a XSS vulnerability is present.
SQL Injection vulnerabilities, which are much different, but often found in web applications along with XSS holes.

External links