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 the same origin policy of client-side scripting languages.

Terminology[]

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 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 rarely used today to refer to cross-site scripting.

Background[]

When Netscape first introduced the JavaScript language, they realized the security risks of allowing a webserver to send executable code to a web 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, 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 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 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.

Real-world examples[]

There are literally hundreds of examples of cross-site scripting vulnerabilities available publicly. 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 encoding. 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, an 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.

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. The 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 and 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.

A similar example, which was more fatal, was found in Indiatimes Email portal by Sandeep Giri (a computer security researcher0. This example demonstrated that if a mailing service is vulnerable to such kind of attack a victim's inbox can be hijacked even if victim doesn't open the mail sent by malicious user.

On October 13, 2005 Samy (a worm virus) exploited a security flaw in MySpace resulting in over one million friend requests being made to its creators profile. Qualifying as a type 2 vulnerability, it used multiple XMLHttpRequests to propogate itself.

Netcraft announced on June 16, 2006. A security flaw in the PayPal web site is being actively exploited by fraudsters to steal credit card numbers and other personal information belonging to PayPal users. The issue was reported to Netcraft via their own anti-phishing toolbar. Soon after, Paypal reported that a "change in some of the code" on the Paypal website had removed the vulnerability.

Avoiding XSS vulnerabilities[]

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 built-in functions or libraries which provide this encoding (in this context, also called quoting or escaping).

External links[]

General[]

Attack vectors[]

Reply post to Pen-Test mailing list by Tom Gallagher in regard to Type 0 attacks and local zone

Cross-site Scripting

Contents