Cross-side scripting attacks typically rely on a malicious user inserting JavaScript into an HTML page, such as into a form. When a browser downloads the HTML, it automatically executes JavaScript code it encounters in the page. Although browsers, at least since Netscape 2.0, have enforced the Same Origin Policy—only JavaScript loaded from the same domain as the HTML page can access or change page properties—a new generation of Web applications use JSON, not HTML, to transmit application data, potentially bypassing the security defined by the Same Origin policy.

According to a recent white paper published by Fortify Software, JavaScript Hijacking [PDF], JSON circumvents the browser's Same Origin protections because:

JavaScript Hijacking allows an attacker to bypass the Same Origin Policy in the case that a Web application uses JavaScript to communicate confidential information. The loophole in the Same Origin Policy is that it allows JavaScript from any website to be included and executed in the context of any other website.

Even though a malicious site cannot directly examine any data loaded from a vulnerable site on the client, it can still take advantage of this loophole by setting up an environment that allows it to witness the execution of the JavaScript and any relevant side effects it may have. Since many Web 2.0 applications use JavaScript as a data transport mechanism, they are often vulnerable while traditional Web applications are not.

The ability for JavaScript loaded from one domain to execute, or evaluate, JavaScript loaded from another site is at the heart of many popular mashups. Sites expecting their data to be used in the context of mashups often make the evaluation of JSON data they present especially easy. The Fortify paper presents a complete example of how using JSON data in that manner can exploited with just a few lines of JavaScript:

When the JSON array arrives on the client, it will be evaluated in the context of the malicious page. In order to witness the evaluation of the JSON, the malicious page [in the example] has redefined the JavaScript function used to create new objects. In this way, the malicious code has inserted a hook that allows it to get access to the creation of each object and transmit the object's contents back to the malicious site. Other attacks might override the default constructor for arrays instead.

Applications that are built to be used in a mashup sometimes invoke a callback function at the end of each JavaScript message. The callback function is meant to be defined by another application in the mashup. A callback function makes a JavaScript Hijacking attack a trivial affair—all the attacker has to do is define the function. An application can be mashup-friendly or it can be secure, but it cannot be both.

If the user is not logged into the vulnerable site, the attacker can compensate by asking the user to log in and then displaying the legitimate login page for the application. This is not a phishing attack—the attacker does not gain access to the user's credentials—so anti-phishing countermeasures will not be able to defeat the attack.

One solutions the paper outlines centers around the server and the client collaborating to include a session-specific cookie in the request that allows the server to detect, and presumable deny, requests originating from a malicious client:

In order to make it easy to detect malicious requests, every request should include a parameter that is hard for an attacker to guess. One approach is to add the session cookie to the request as a parameter. When the server receives such a request, it can check to be certain the session cookie matches the value in the request parameter. Malicious code does not have access to the session cookie (cookies are also subject to the Same Origin Policy), so there is no easy way for the attacker to craft a request that will pass this test... As long as the secret is hard to guess and appears in a context that is accessible to the legitimate application and not accessible from a different domain, it will prevent an attacker from making a valid request.

Another solution outlined in the paper makes it impossible to execute JavaScript merely through the script tag:

In order to make it impossible for a malicious site to execute a response that includes JavaScript, the legitimate client application can take advantage of the fact that it is allowed to modify the data it receives before executing it, while a malicious application can only execute it using a script tag. When the server serializes an object, it should include a prefix (and potentially a suffix) that makes it impossible to execute the JavaScript using a script tag. The legitimate client application can remove this extraneous data before running the JavaScript.

Many developers prefer JSON to other data formats precisely because JSON can be evaluated inside JavaScript through the eval() function. As the Fortify paper shows, though, simply evaluating code downloaded from the network may not be a good idea.

JavaScript is often used as a type of mobile code. In the context of Java, Jini's security framework has already defined a set of behaviors and technologies required to support mobile code akin to JSON. (See Bill Venners' interview with Bob Scheifler, Jini Security, for more details on Jini security.)

What do you think client-side technologies can learn from the Jini model? What other implications do think there are for mobile code on the client side?