Cross-site scripting

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Recently, vulnerabilities of this kind have been exploited to craft powerful phishing attacks and browser exploits. Cross-site scripting was originally referred to as CSS, although this usage has been largely discontinued

 

Background

When Netscape first introduced the JavaScript language, they realized the security risks of allowing a Web server to send executable code to a browser (even if only in a browser sandbox). One key problem with this is the case where users have more than one browser window open at once. In some instances, a 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 Web site could attempt to steal sensitive information this way. In order to fix this problem, browsers introduced the same origin policy. Essentially, this policy allows any interaction between objects and pages that originated from the same domain and over the same protocol. That way, a malicious Web site would not 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 Web sites. In general, cross-site scripting holes can be seen as vulnerabilities present in web pages 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 access privileges to sensitive page content, session cookies, and a variety of other objects.
Terminology
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 use of the abbreviation XSS was by Steve Champeon in his Webmonkey article “XSS, Trust, and Barney”. In 2002, Steve also posted the suggestion of using XSS as an alternative abbreviation to the Bugtraq mailing list. In a rare show of unity, the security community quickly adopted the alternative, and CSS is seldom used today to refer to cross-site scripting, although a few existing pages still use it this way.

 

Types
As of now three distinct types of XSS vulnerability are known. (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 is not 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 its own page, and this information is not encoded using HTML entities, an 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 (see below), except in one very important situation. Because of the way Internet Explorer treats client-side script in objects located in the “local zone” (for instance, on the client’s local hard drive), an 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, a 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 encoding, 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 the search string will be redisplayed 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 occurrences of the search terms are not HTML entity encoded, an XSS hole will result.

At first blush, this does not 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 a 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 encoded using HTML entities. 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 the script just once. This could potentially hit a large number of other users with little need for social engineering or the web application could even be infected by a cross-site scripting virus.

The methods of injection can vary a great deal, and an attacker may not need to 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 encoded prior to re-display in a dynamic page, else an XSS vulnerability of this type could result