Although the term "Web 2.0" does not have a rigorous definition, it is commonly used in at least two ways. First, it refers to Web applications that encourage social interaction or collective contribution for a common good. Second, it refers to Web programming techniques that lead to a rich and user-friendly interface. These techniques sometimes go by the name Asynchronous JavaScript and XML (AJAX), though many implementations don't use XML at all. In some cases, the social and technical aspects of Web 2.0 come together in the form of mashups: Web applications that are built by assembling pieces from multiple independent Web applications.

This article describes a vulnerability we call JavaScript Hijacking. It's an attack against the data transport mechanism used by many rich Web applications. JavaScript Hijacking allows an unauthorized attacker to read confidential data from a vulnerable application using a technique similar to the one commonly used to create mashups. The vulnerability is already being discussed in some circles, but most Web programmers are unaware that the problem exists, and even fewer security teams understand how widespread it is.

Traditional Web applications are not vulnerable to JavaScript Hijacking because they don't use JavaScript as a data transport mechanism. To our knowledge, this is the first class of vulnerability that is specific to rich Web applications. In essence, JavaScript Hijacking is possible because the security model implemented by all popular Web browsers doesn't anticipate the use of JavaScript for communicating confidential information.

JavaScript Hijacking builds on another type of widespread vulnerability: cross-site request forgery. A cross-site request forgery attack causes a victim to unwittingly submit one or more HTTP requests to a vulnerable Web site. A typical cross-site request forgery attack compromises data integrity - it gives an attacker the ability to modify information stored by a vulnerable Web site. JavaScript Hijacking is more dangerous because it also compromises confidentiality - an attacker can read a victim's information.

Vulnerable Web sites have already been found in the wild. One of the first people to demonstrate JavaScript Hijacking was Jeremiah Grossman, who identified a vulnerability in Google Gmail. (Google has fixed the problem.) Google was serving Gmail users' contacts in unprotected JavaScript, so an attacker could steal the contact list using JavaScript Hijacking.

During the course of our work, we examined 12 popular AJAX frameworks, including four server-integrated toolkits and eight purely client-side libraries. We found that only one of the 12 took measures to prevent JavaScript Hijacking. Preventing JavaScript Hijacking requires a secure server-side implementation, but it is incumbent upon the client-side libraries to promote good security practices. Currently, some of the client-side libraries go so far as to require the server side to contain a JavaScript Hijacking vulnerability.