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 gets 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. A different secret can also be used in place of the session cookie. 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.

Some frameworks run only on the client side. In other words, they are written entirely in JavaScript and have no knowledge of the workings of the server. This implies that they do not know the name of the session cookie. Even without knowing the name of the session cookie, they can participate in a cookie-based defense by adding all of the cookies to each request to the server. The following JavaScript fragment outlines this "blind client" strategy:

var httpRequest = new XMLHttpRequest();
...
var cookies="cookies="+escape(document.cookie);
http_request.open(‘POST', url, true);
httpRequest.send(cookies);

The server could also check the HTTP referrer header to make sure the request has originated from the legitimate application and not from a malicious application. Historically speaking, the referrer header has not been reliable, so we don't recommend using it as the basis for any security mechanism.

A server can mount a defense against JavaScript Hijacking by responding only to HTTP POST requests and not responding to HTTP GET requests. This is a defensive technique because the <script> tag always uses GET to load JavaScript from external sources. This defense is also error-prone. The use of GET for better performance is encouraged by Web application experts from Sun and elsewhere. Even frameworks that use POST requests internally, such as GWT, document the steps necessary to support GET requests without mentioning any potential security ramifications. This missing connection between the choice of HTTP methods and security means that, at some point, a programmer may mistake this lack of functionality for an oversight rather than a security precaution and modify the application to respond to GET requests.

Preventing Direct Execution of the Response
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. There are many possible implementations of this approach. We will outline two.

First, the server could prefix each message with the statement:

while(1);

Unless the client removes this prefix, evaluating the message will send the JavaScript interpreter into an infinite loop. This is the technique Google used to fix the vulnerability Grossman identified. The client searches for and removes the prefix like this:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
if (txt.substr(0,9) == "while(1);") {
txt = txt.substring(10);
}
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);

Second, the server can include comment characters around the JavaScript that have to be removed before the JavaScript is sent to eval(). The following JSON object has been enclosed in a block comment:

/*
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
"purchases":60000.00, "email":"brian@fortify.com" }
]
*/

The client can search for and remove the comment characters like this:

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;if (txt.substr(0,2) == "/*") {
txt = txt.substring(2, txt.length - 2);
}
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);

Any malicious site that retrieves the sensitive JavaScript via a <script> tag will not gain access to the data it contains.

Conclusion and Recommendations
The JavaScript implementations contained in popular Web browsers have been the source of numerous security problems, so JavaScript Hijacking follows a distinguished list of older attacks, including cross-site scripting and cross-site request forgery. (Bugs in JavaScript implementations have also led to no shortage of browser vulnerabilities.) The fundamental issue that allows JavaScript Hijacking, an eccentricity in the Web browser Same Origin Policy, is also used by benevolent programmers to create legitimate advertisements and application mashups, so it is unlikely that the Same Origin Policy will change in the near future.

The solutions and best practices proposed in this article have been cobbled together in much the same way that rich Web interfaces and mashup concepts have been cobbled together. The Web programming community has stretched the existing technology well past its original purposes, so it is not surprising that we occasionally encounter an unexpected side effect. These workarounds and hacks will be necessary until popular Web browsers support standards that allow for things like secure cross-domain requests and JavaScript sandboxing. Until then, we need to make programmers aware of the risks inherent in communicating confidential data via JavaScript.

To that end, we recommend that all programs that communicate using JavaScript take the following defensive measures:

• Include a hard-to-guess identifier, such as the session identifier, as part of each request that will return JavaScript. This defeats cross-site request forgery attacks by allowing the server to validate the origin of the request.
• Include characters in the response that prevent it from being successfully handed off to a JavaScript interpreter without modification. This prevents an attacker from using a <script> tag to witness the execution of the JavaScript.

We need to encourage Web application frameworks to be secure by default. For server-integrated toolkits, this is a matter of changing both the server-side and client-side components. Purely client-side libraries cannot defend against JavaScript Hijacking without support from server-side code, but they can still improve security by making the JavaScript Hijacking risk clear to developers and by including features that make it easy to implement secure server-side code.

If programmers want to create applications that can participate as part of a mashup, they should be required to explicitly disable a security constraint, and the framework should make them aware of the consequences of their actions.

Acknowledgments
We would like to extend special thanks to a number of people for their feedback on early versions of this article. We thank Jeremiah Grossman for his valuable comments on the technical content of the report, Joe Walker - for a great discussion of DWR security, Alex Russell - for a discussion of the Dojo framework and for highlighting important points missing from the original draft, and Bob Ippolito - for a discussion of the MochiKit framework and suggestions on how to address the issue. Eddie Lee, Adam Murray, and Erik Cabetas helped us proofread the draft and provided insight into their experience with AJAX and AJAX frameworks.