JavaScript: The Definitive Guide

Previous Chapter 20
JavaScript Security
Next
 

20.2 Security Holes and Security Hobbles

The approach to JavaScript security in Navigator 2.0 and 3.0 has been to first identify security holes through which private information could be exported, and then to plug those holes. Typically, security holes are plugged by implementing a "security hobble"--i.e., by restricting or "hobbling" the capabilities of JavaScript so that the hole cannot be exploited. For example, the History object in client-side JavaScript is an array of the URLs that the user has previously visited during the current browsing session. Because this information is private, JavaScript has been hobbled so that it cannot access the elements of this array. Because of this hobble, we are left with a History object that supports only forward(), back(), and go() methods.

The problem with an identify-and-patch approach is that it can be difficult to identify security holes, and that there is no way of knowing when you've found all possible holes. A web browser is a complex thing, and JavaScript is a powerful scripting language. In Navigator 2.0 and 2.0.1, these two facts intersected to produce a number of security holes that had not been patched. For example, in Navigator 2.0, a JavaScript program could open a new window to display the special about:cache URL. Then it could read the links[] array of the document of that window to obtain information about cached files (and hence browsing history) of the client browser. This information could be placed in hidden fields of an HTML form and submitted to the web server without the user's knowledge. The about:cache URL could be displayed in a window so small that the user wouldn't notice it, or it could even be displayed in an invisible frame (i.e., one with zero height). A similar attack used the file:/// URL to discover the contents of the root directory of the client's system, and could recursively proceed to determine the client's entire directory structure.

Another attack, one that was undoubtedly exploited to some extent on the Internet, allowed a JavaScript program to automatically send email to any desired address whenever the user visited a web page. What this does, of course, is steal the email address of everyone who visits a page. This attack was accomplished by using the submit() method of the Form object to automatically submit an empty (and invisible) HTML form to a mailto: URL.

Not all security holes in Navigator 2.0 and 2.0.1 were the result of unforeseen interactions between the features of JavaScript and the rest of Navigator. Some were just bugs, plain and simple. For example, one bug allowed a web page to leave JavaScript code behind after it was unloaded. This code could do anything it wanted to. It could violate security by checking the URL of the document currently being viewed once every second and sending that information off to a web server or email address. Instead of publicizing a user's browsing history, this security hole publicized a user's browsing future!

Another serious bug-induced security hole was related to a bug in the security hobble for the FileUpload form element. JavaScript is hobbled so that it is not allowed to set the filename that appears in the FileUpload element. If it could set it, it would clearly be trivial to send the contents of any file on the client's computer (a password file, perhaps) across the network to a web server, an obviously grave breach of security. Unfortunately, there the hobble that prevented this was not sufficient, and there was a straightforward trick that would allow a JavaScript program to specify what file was to be uploaded. Fortunately, this trick was not publicized, and a new version of Navigator, with this bug fixed, was quickly released.[1]

[1] For more information on this and other Netscape 2.0 and 2.0.1 security holes, see the "JavaScript Problems I've Discovered" web pages by John Robert LoVerso of the OSF Research Institute at http://www.osf.org/~loverso/javascript.

Many of the security holes discovered in Navigator 2.0 were patched with hobbles in Navigator 2.0.1, and Netscape even added the option to disable JavaScript entirely (the ultimate hobble) in this version of the browser. Unfortunately, a new crop of holes were discovered almost as soon as 2.0.1 was released. Because of the continuing problem with security holes, and because of the resulting bad press, Netscape soon released Navigator 2.0.2, which fixed all known security-related bugs and implemented a very general hobble that would, hopefully, spell an end to security holes. With this hobble implemented, a JavaScript program is not allowed to read the properties of any window (or frame) or the properties of any objects within a window if the contents of that window were loaded from a different web server than the JavaScript program itself. This hobble rules out a whole class of security holes. It means that a program cannot open a new window to display about:cache, file:///, or some other URL and extract information from that URL. This hobble is particularly important when a corporate firewall is in use--it prevents a script loaded from the Internet from opening a new window and going browsing in a private intranet.

The bug fixes and the mega-hobble in Navigator 2.0.2 were included in Navigator 3.0 and appear to have been quite effective at patching security holes--there has been a long spell without any new ones being discovered. Unfortunately a new hole has recently been discovered. The hobble that was inserted to prevent automatic submission of a form to a mailto: URL only worked for certain form encodings and methods. Embarrassingly for Netscape, it turns out that other combinations of form submission methods and encodings still allow a form to be automatically submitted without user confirmation, effectively stealing the user's email address. By the time this book is published, the hobble will have been strengthened, and this security hole will have been patched (for good this time, we hope) in Navigator 3.0.1.

Security Hobbles in Navigator 3.0

The following is a complete list of security hobbles in Navigator 3.0.1. While not all earlier versions of Navigator implement all of these hobbles, you should assume that they are all in place, if you want your code to be portable to the latest versions of Navigator. If you are yourself worried about private information being exported through security holes, then you should of course upgrade to the most recent version of Navigator that has all of these hobbles implemented.

Security in Internet Explorer

Since Internet Explorer 3.0 has not been around as long and is not used as commonly as Navigator, it has not been subjected to such intense scrutiny, as Netscape's browser was. Thus, while IE does not have a history of security holes its implementation of JavaScript, there may yet be holes discovered.

The one known JavaScript security hole in Internet Explorer is a major one. IE does not contain the security hobble described above which prevents a script from one URL from reading the properties of a script from another URL. This means, for example, that if you use IE on Windows 95, a script could load the contents of a URL like file:///C|\Windows\StartMenu\ into a hidden frame, and then examine the links[] array of that frame to determine what programs you have installed in your Windows start menu. This private information might then be submitted in a hidden field of some innocuous looking form.


Previous Home Next
JavaScript and Security Book Index The domain Property

HTML: The Definitive Guide CGI Programming JavaScript: The Definitive Guide Programming Perl WebMaster in a Nutshell
Hosted by uCoz