JavaScript and browser security	247

Security is an increasingly important concern for Internet services. The Web is inherently nonsecure, and adding proper security measures to an Ajax application can be a strong differentiator for a product. Clearly, if a user’s money is involved in any way, such as online shopping or providing a service that he has paid for, giving due consideration to security is essential.

Security is a big topic and deserves its own book. Many of the security issues that an Ajax application faces are the same as for a classical web application. For these reasons, we’ll limit our discussion to security-related concerns that have particular implications for Ajax. First, we’ll look at the security implications of shunting executable scripts around the network, and the steps that the browser vendors have taken to make this a safe experience. We’ll also see the steps that may be taken to relax these safeguards, with the user’s compliance. Second, we’ll look at protecting a user’s data when it is submitted to the server, allowing a user to work with our Ajax services confidently. Finally, we’ll describe ways to secure the data services that our Ajax clients use to prevent them from being used illegitimately by external entities on the network. Let’s kick off now with a look at the security implications of sending our client across the network.

7.1 JavaScript and browser security

When an Ajax application is launched, the web server sends a set of JavaScript instructions to a web browser running on a different machine, about which it knows very little. The browser proceeds to execute these instructions. In letting their web browser do this, the user of an Ajax application is placing a significant amount of trust in the application and its authors. The browser vendors and standards bodies recognized that this trust was not always appropriate, and have put safeguards in place to prevent it from being abused. In this section, we’ll look at the safeguards and how to work with them. We’ll then discuss situations where the constraints aren’t appropriate and can thus be relaxed. The ability to talk directly to third-party web services is one such situation that should be of particular interest to Ajax developers.

Before diving any further into this topic, let us define what we mean by “mobile code.” Everything on the hard disk of a computer is just a clump of binary data. We can distinguish, however, between data that is purely descriptive and data that represents machine instructions that can be executed. Descriptive data can do nothing until some executing process picks it up. In the early client/ server applications, the client was installed on the user’s machine just like any other desktop application, and all traffic over the network was purely descriptive

248CHAPTER 7

Security and Ajax

data. The JavaScript code of an Ajax application, however, is executable code. As such, it offers the potential to do many more exciting things than “dead” data can. It can also be more dangerous. We describe code as mobile if it is stored on one machine and can transmit itself across the network to execute on another. The computer receiving the mobile code needs to consider whether it should trust the sender of the code, particularly over the public Internet. To what system resources should it grant access?

7.1.1Introducing the “server of origin” policy

We noted that, when executing JavaScript in a web browser, a user is letting code written by somebody they don’t know run on their own machine. Mobile code, capable of running automatically over a network in this fashion, is a potential security risk. In response to the potential dangers of mobile code, browser vendors execute JavaScript code in a sandbox, a sealed environment with little or no access to the computer’s resources. An Ajax application can’t read or write to the local filesystem. Nor can it establish network connections to any web domain other than the one from which it originated, in most cases. A programmatically generated IFrame can load pages from other domains and execute code, but the scripts from the two domains cannot interact with each other. This is sometimes referred to as the “server of origin” policy.

Let’s take a (very) simple example. In our first script file, we define a variable:

x=3;

In the second script file, we make use of that variable:

alert(top.x+4);

The first script is included into our top-level document, which opens up an IFrame and loads a page that includes the second script into it (figure 7.1).

If both scripts are hosted on the same domain, then the alert fires successfully. If not, a JavaScript error is thrown instead, and the second script fails.

7.1.2Considerations for Ajax

In the script-centric interaction that we discussed in chapter 5, JavaScript code is retrieved from the server and evaluated on the fly. In most cases, the client is consuming code from its own server, but let’s consider the case where it is running code from a different domain, often referred to as “cross-scripting.” Allowing the user to download scripts from arbitrary sites would open up the potential for a lot of mischief, effectively letting third parties re-author or deface websites by using

JavaScript and browser security	249

Web browser

Frame 1 Frame 2

var x=3;			alert( top.x );

Figure 7.1

The JavaScript security model prevents scripts from different domains from interacting with one another.

DOM manipulation, for example. The limitations imposed by the JavaScript security model offer real protection from this kind of exploit. The model also prevents malicious sites from downloading your Ajax client code directly from your website and pointing it at a different server without your users knowing that they were talking to a different back-end.

In a data-centric interaction, the risk is slightly less, as the server is delivering data rather than live code. Nonetheless, if delivered from a third-party server the data might contain information crafted to do harm when parsed. For example, it might overwrite or delete vital information, or cause resources to be consumed on the server.

7.1.3Problems with subdomains

Finally, note that web browsers have a fairly limited notion of what constitutes the same domain and can err frustratingly on the side of caution. The domain is identified solely by the first portion of the URL, with no attempt to determine whether the same IP address backs the two domains. Table 7.1 illustrates a few examples of how the browser security model “thinks.”

Table 7.1 Examples of cross-browser security policy

	URLs	Cross-Scripting	Comments
		Allowed?
	http://www.mysite.com/script1.js	Yes	As expected!
	http://www.mysite.com/script2.js

continued on next page

250CHAPTER 7

Security and Ajax

Table 7.1 Examples of cross-browser security policy (continued)

	URLs	Cross-Scripting	Comments
		Allowed?
	http://www.mysite.com:8080/script1.js	No	The port numbers don’t match (script
			1 is served from port 8080).
	http://www.mysite.com/script2.js
	http://www.mysite.com/script1.js	No	The protocols don’t match (script 2
			uses a secure HTTP protocol).
	https://www.mysite.com/script2.js
	http://www.mysite.com/script1.js	No	ww.mysite.com resolves to IP address
			192.168.0.1, but the browser doesn’t
	http://192.168.0.1/script2.js
			try to work this out.
	http://www.mysite.com/script1.js	No	Subdomains are treated as separate
			domains.
	http://scripts.mysite.com/script2.js
	http://www.myisp.com/dave/script1.js	Yes	Although the scripts come from sites
			owned by different people, the domain
	http://www.myisp.com/eric/script2.js
			is the same.
	http://www.myisp.com/dave/script1.js	No	www.mysite.com points to
			www.myisp.com/dave, but the browser
	http://www.mysite.com/script2.js
			won’t check this.

In the case of subdomains, it is possible to truncate the part of the domain being matched by setting the document.domain property. Thus, for example, in a script served from http://www.myisp.com/dave, we can add a line to the script stating

document.domain='myisp.com';

which would allow interaction with a script served from the subdomain http:// dave.myisp.com/, provided that it too sets the document.domain value. It isn’t possible to set my document.domain to an arbitrary value such as www.google.com, however.

7.1.4Cross-browser security

Our discussion wouldn’t be complete without pointing out a glaring crossbrowser inconsistency. Internet Explorer security operates on a series of “zones,” with more or less restrictive security permissions. By default (for Internet Explorer 6, at least), files executing on the local filesystem are given permission to contact websites on the Internet without the user being prompted, with the