21.1 JavaScript and Security

JavaScript's first line of defense against malicious code is that the language simply does not support certain capabilities. For example, client-side JavaScript does not provide any way to write or delete files or directories on the client computer. With no File object and no file access functions, a JavaScript program cannot delete a user's data or plant viruses on the user's system.

Similarly, client-side JavaScript has no networking primitives of any type. A JavaScript program can load URLs and can send HTML form data to web servers, CGI scripts, and email addresses, but it cannot establish a direct connection to any other hosts on the network. This means, for example, that a JavaScript program cannot use a client's machine as an attack platform from which to attempt to crack passwords on another machine. (This would be a particularly dangerous possibility if the JavaScript program had been loaded from the Internet through a firewall and could then attempt to break into the intranet protected by the firewall.)

Although the core JavaScript language and the basic client-side object model lack the filesystem and networking features that most malicious code requires, the situation is not quite as simple as it appears. In many web browsers, JavaScript is used as a "script engine" for other software components, such as ActiveX controls in Internet Explorer and plugins in Netscape. These components may have filesystem and network capabilities, and the fact that JavaScript programs can control them clouds the picture and raises security concerns. This is particularly true with ActiveX controls, and Microsoft has at times had to release security patches to prevent JavaScript code from exploiting the capabilities of scriptable ActiveX objects. We'll touch on this issue again briefly at the end of this chapter.

While this intentional lack of features in client-side JavaScript provides a basic level of security against the most egregious attacks, other security issues remain. These are primarily privacy issues -- JavaScript programs must not be allowed to export information about the user of a browser when that information is supposed to be private.

When you browse the Web, one of the pieces of information you are by default consenting to release about yourself is which web browser you use. As a standard part of the HTTP protocol, a string identifying your browser, its version, and its vendor is sent with every request for a web page. This information is public, as is the IP address of your Internet connection, for example. Other information, however, should not be public: this includes your email address, which should not be released unless you choose to do so by sending an email message or authorizing an automated email message to be sent under your name.

Similarly, your browsing history (the record of which sites you've already visited) and the contents of your bookmarks list should remain private. Your browsing history and bookmarks say a lot about your interests; this is information that direct marketers and others pay good money for so that they can target sales pitches to you more effectively. You can be sure that if a web browser or JavaScript allowed this valuable private information to be stolen, some people would steal it every time you visited their sites, and it would be on the market only seconds later. Most web users would be uncomfortable knowing that any site they visited could find out that they were cat fanciers, for example, who were also interested in women's footwear and the Sierra Club.

Even assuming that we have no embarrassing fetishes to hide, there are plenty of good reasons to be concerned about data privacy. One such reason is a pragmatic concern about receiving electronic junk mail (spam) and the like. Another is a legitimate concern about keeping secrets. We don't want a JavaScript program loaded from the Internet and running in one web browser window to be able to start examining the contents of other browser windows that contain pages loaded from the company intranet behind the firewall. The remainder of this chapter explains how JavaScript defends itself against such abuses.