20.1 JavaScript and Security

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

Similarly, client-side JavaScript has no networking primitives of any type. A JavaScript program can load URLs and send HTML form data to web servers and CGI scripts, 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 a attack platform from which to attempt to crack passwords on other machines. (This would be a particularly dangerous possibility if the JavaScript program has been loaded from the Internet, through a firewall, and then could attempt to break into the intranet protected by the firewall.)

While the JavaScript language itself provides this basic level of security against the most egregious attacks, there are other security issues that remain. Primarily these are 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 consenting to release about yourself is the web browser that you use: it is a standard part of the HTTP protocol that a string identifying your browser, version, and 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. But other information should not be public. This includes your email address, for example, 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 (what sites you've already visited) and the contents of your bookmarks list should remain private. Because your browsing history and bookmarks say a lot about your interests, this is information that direct marketers and others would pay good money for, so that they can more effectively target sales pitches to you. Because this information is so valuable, you can be sure that if a web browser or JavaScript allowed this private information to be stolen, someone would be stealing it every time you visited their site. Once stolen, it would be on the market only nanoseconds later. Most users of the Web would be uncomfortable with the idea that any site they visit could find out that they are cat fanciers who are 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 and the like. Another is a very legitimate concern about keeping secrets. We don't want a JavaScript program to be able to start examining data behind our corporate firewall or to upload our passwords file to its web server, for example. At a more general level, we might desire that our private data be protected simply because we believe that individuals should have control over the ways that their personal data is collected and used.

Navigator and other browsers already have the ability to establish secure communication channels on the Web so that the information transferred back and forth between web server and web client remains private. By turning static HTML into dynamic programs, JavaScript opens the door to unethical web pages that steal private information and send it (through secure or insecure channels) back to the web server. It is this possibility that JavaScript must defend against. The remainder of this chapter explains how JavaScript does this, and also documents cases where it has failed to do it.