Cross-site scripting – part 2

Exploit scenarios
Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. (The names below come from the cast of characters commonly used in computer security.)

Type-0 attack

Mallory sends a URL to Alice (via email or another mechanism) of a maliciously constructed web page. 
Alice clicks on the link. 
The malicious web page’s JavaScript opens a vulnerable HTML page installed locally on Alice’s computer. 
The vulnerable HTML page contains JavaScript which executes in Alice’s computer’s local zone. 
Mallory’s malicious script now may run commands with the privileges Alice holds on her own computer. 

Type-1 attack

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 email, making it look as if it came from Bob (ie. the email 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.


Type-2 attack

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 webserver without their knowledge. 
Later, Mallory logs in as other site users and posts messages on their behalf…. 
Please note, the preceding examples are merely a representation of common methods of exploit and are not meant to encompass all vectors of attack.

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 famous example for type 1 XSS vulnerabilities: Two XSS vulnerabilities in Google.com website were identified and published by Yair Amit in December 2005. The vulnerabilities allowed an attacker to impersonate legitimate members of Google’s services or to mount a phishing attack. This publication presented an obscure way to bypass common XSS countermeasures by using UTF-7 encoded payloads. 
Two type 1 XSS vulnerabilities were exploited humorously, in August 2006, through a fake news summary which claimed President Bush appointed a 9 year old boy to be the chairperson of the Information Security Department. This claim was backed up with links to cbsnews.com and www.bbc.co.uk, both of which were vulnerable to separate XSS holes which allowed the attackers to inject an article of their choosing.

An example of a type 2 vulnerability was found in Hotmail, in October 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. 
Netcraft announced on June 16, 2006 that 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.

On October 13, 2005 Samy 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 propagate itself. 
An XSS vulnerability in Community Architect Guestbook was disclosed by Susam Pal on April 19, 2006 which can be exploited by malicious people to conduct script insertion attacks. As a result, many free web-hosting services which used the guestbook were vulnerable to such attacks.

 

On November 8th 2006 Rajesh Sethumadhavan discovered a type 2 vulnerability in the social network site Orkut which would make it possible for Orkut members to inject HTML and JavaScript into their profile [1]. Rodrigo Lacerda used this vulnerability to create a cookie stealing script known as the Orkut Cookie Exploit which was injected into the Orkut profiles of the attacking member(s). By merely viewing these profiles unsuspecting targets had the communities they owned transferred to a fake account of the attacker. On December 12th, Orkut fixed the vulnerability. 
On March 2, 2007 Sebastian Bauer discovered an XSS flaw in knorr.de login page. 
On June 1, 2007 Luke Day discovered an XSS flaw in habbohotel.com news page, which allowed users to steal session info, qualifying as a type 2 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).

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.

The ultimate problem with trying to avoid XSS vulnerabilities is that every situation is different. For any given situation, the needs and the issues change. For instance, if user input is going into the src attribute of a hyperlink, cgi.escape() would not be sufficient. Let’s say a picture was to be added to a page of pictures, in this fashion:

<img src=’$url’>
An attacker could enter “doesntexist.jpg’ onerror=’alert(document.cookie)” to add an event which triggers when the browser fails to load “doesntexist.jpg”, executing the code.

If one were to implement a function like cgi.escape() (which comes with Python), one would be best off converting <, >, &, ” and ‘ characters to their equivalent HTML entity.

As stated above, the unfortunate consequence of this fix is that users are prevented from embedding 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 difficult to reliably cleanse script from normal HTML. The most reliable method is for web applications to parse the HTML, strip tags and attributes that do not appear in a whitelist, and output valid HTML.

 

Related vulnerabilities

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

  • Cross Zone Scripting vulnerabilities, which exploits “zone” concepts in software, usually execute code with a greater privilege.
  • 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 request forgery (CSRF/XSRF) is almost the opposite of XSS, in that rather than exploiting the user’s trust in a site, the attacker exploits the site’s trust in the client software, submitting requests that the site believes come from its own pages