Chapter 21. JavaScript Security Because of the wide-open nature of the Internet, security is an important issue. This is particularly true with the introduction of languages such as Java and JavaScript, because they allow executable content to be embedded in otherwise static web pages. Since loading a web page can cause arbitrary code to be executed on your computer, stringent security precautions are required to prevent malicious code from doing any damage to your data or your privacy. This chapter discusses Internet security issues related to JavaScript. Note that this chapter does not cover any of the many other issues involved in web security, such as the authentication and cryptographic technologies used to keep the contents of web documents and HTML forms private while they traverse the Web. es er's data or plant viruses on the user's system. Similarly, client-side JavaScript has no networking primitives of any type. A JavaScript other machine. (This would be a particularly dangerous possibility if the JavaScript program d then attempt to break into lthough the core JavaScript language and the basic client-side object model lack the code requires, the situation is not vaScript is used as a "script ch as ActiveX controls in Internet Explorer and lesystem 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 t the to be private. 21.1 JavaScript and Security JavaScript's first line of defense against malicious code is that the language simply do 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 us 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 an had been loaded from the Internet through a firewall and coul the intranet protected by the firewall.) A filesystem and networking features that most malicious quite as simple as it appears. In many web browsers, Ja engine" for other software components, su plugins in Netscape. These components may have fi capabilities of scriptable ActiveX objects. We'll touch on this issue again briefly a 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 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 t our onnection, 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 er Similarly, your browsing history (the record of which sites you've already visited) and the 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 s, and k 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 pany intranet behind the ewall. The remainder of this chapter explains how JavaScript defends itself against such abuses. 21.2 Restricted Features As I've already mentioned, the first line of defense against malicious scripts in client-side JavaScript is that the language simply omits certain capabilities. The second line of defense is that JavaScript imposes restrictions on certain features that it does support. For example, client-side JavaScript supports a close( ) method for the Window object, but most (hopefully all) web-browser implementations restrict this method so that a script can close only a window that was opened by a script from the same web server. In particular, a script cannot close a window that the user opened; if it tries to do so, the user is presented with a confirmation box asking if he really wants to close the window. h rity restrictions to go along with them. the HTTP protocol, a string identifying your browser, its version, and its vendor is sen with every request for a web page. This information is public, as is the IP address of y ternet cIn sending an email message or authorizing an automated email message to be sent und your name. 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 information to be stolen, some people would steal it every time you visited their site 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 jun running in one web browser window to be able to start e rowser windows that contain pages loaded from the com xamining the contents of other b fir The most important of these security restrictions is known as the same-origin policy and is described in the next section. The following is a list of the other security restrictions found in most implementations of client-side JavaScript. This is not a definitive list. Eac browser may have a slightly different set of restrictions, and the proprietary features of each browser may well have proprietary secu x The History object was originally designed as an array of URLs that represented ns of d uld d the user's . This prevents malicious scripts from calling browsing window, thereby causing the program to exit. x A script cannot open a window that is smaller than 100 pixels on a side or cause a window to be resized to smaller than 100 pixels on a side. Similarly, such a script cannot move a window off the screen, or create a window that is larger than the screen. This prevents scripts from opening windows that the user cannot see or could easily overlook; such windows could contain scripts that keep running after the user thinks they have stopped. Also, a script may not create a browser window without a titlebar, because such a window could be made to spoof an operating- system dialog box and trick the user into entering a sensitive password, for example. x A script may not cause a window or frame to display an about: URL, such as about:cache, because these URLs can expose system information, such as the script cannot set any of the properties of an Event object. This prevents scripts from spoofing events. A script cannot register event listeners within for or capture ion. w l of the properties of the Document object. For all intents and purposes, you the complete browsing history of the browser. Once the privacy implicatio this became apparent, however, all access to the actual URLs was restricted, an the History object was left with only its back( ), forward( ), and go( ) methods to move the browser through the history array without revealing the contents of the array. x The value property of the FileUpload object cannot be set. If this property co be set, a script could set it to any desired filename and cause the form to uploa the contents of any specified file (such as a password file) to the server. x A script cannot submit a form (using the submit( ) method of the Form object, for example) to a mailto: or news: URL without the user's explicit approval through a confirmation dialog box. Such a form submission would contain the user's email address, which should not be made public without obtaining permission. x A JavaScript program cannot close a browser window without user confirmation unless it opened the window itself self.close( ) to close the user's contents of the browser's cache. x A events for documents loaded from different sources than the script. This prevents scripts from snooping on the user's input (such as the keystrokes that constitute a password entry) to other pages. 21.3 The Same-Origin Policy There is one far-reaching security restriction in JavaScript that deserves its own sect This restriction is known as the same-origin policy: a script can read only the properties of windows and documents that have the same origin (i.e., that were loaded from the same host, through the same port, and by the same protocol) as the script itself. The same-origin policy does not actually apply to all properties of all objects in a w from a different origin. But it does apply to many of them, and in particular, it applies to practically al indo should consider all predefined properties of all client-side objects with different origins The same-origin policy is a fairly severe restriction, but it is necessary to prevent scripts from stealing proprietary information. Without this restriction, an untrusted script (perhaps a script loaded through a firewall into a browser on a secure corporate intranet) in one window could use DOM methods to read the contents of documents in other browser windows, which might contain private information. Still, there are circumstances in which the same-origin policy is too restrictive. It poses particular problems for large web sites that use more than one server. For example, a script from home.netscape.com might legitimately want to read properties of a document loaded from developer.netscape.com, or scripts from orders.acme.com might need to read properties from documents on catalog.acme.com. To support large web sites of this sort, JavaScript 1.1 introduced the domain property of the Document object. By default, the domain property contains the hostname of the server from which the document was loaded. You can set this property, but only to a string that is a valid domain suffix of itself. Thus, if domain is originally the string "home.netscape.com", you can set it to the string "netscape.com", but not to "home.netscape" or "cape.com", and certainly not to "microsoft.com". (The domain value must have at least one dot in it; you cannot set it to "com" or any other top-level domain.) g Zo nd Signed Scripts policy is too the interesting and useful things we too permissive, untrusted scripts policy to be configured so that trusted scripts are subject to fewer security restrictions than untrusted scripts. The two major browser vendors, Microsoft and Netscape, have taken different approaches to allowing configurable security; their approaches are briefly described in this section. ts nes.) off-limits to your scripts. User-defined properties of objects with different origins may also be restricted, although this may vary from implementation to implementation. If two windows (or frames) contain scripts that set domain to the same value, the same- origin policy is relaxed for these two windows and each of the windows may read properties from the other. For example, cooperating scripts in documents loaded from orders.acme.com and catalog.acme.com might set their document.domain properties to "acme.com", thereby making the documents appear to have the same origin and enablin each document to read properties of the other. 21.4 Security nes a A one-size-fits-all security policy is never entirely satisfactory. If the restrictive, trusted scripts don't have the ability to do would like them to do. On the other hand, if the policy is may cause havoc! The ideal solution is to allow the security Internet Explorer defines "security zones" in which you can list web sites whose scrip you trust and web sites whose scripts you do not trust. You can then configure the security policies of these two zones separately, giving more privileges to and placing fewer restrictions on the trusted sites. (You may also separately configure the privileges of internet and intranet sites that are not explicitly listed in either of the other two zo Unfortunately, this is not a complete or fine-grained solution for JavaScript security, s that IE allows you to configure are not directly related to JavaScript. In IE 6 beta, for example, you can specify whether scripts are ng d ation. s " ty policies and do it in a way that is cryptographically secure and theoretically very nology, the process of hnology has never really caught on. rson or organization that wrote or otherwise takes respons a signed curity restrictions described earlier, it first s it to do so. When a script requests a privilege, the browser defers to the user. The user is told who the signer of the script is and is asked whether she wants to grant the requested privilege to a script written by that person or organization. Once the user makes the decision, she can have the browser remember it so that she doesn't get asked the same question in the future. In effect, this procedure allows a user to configure a fine-grained customized security policy on the fly, as the need arises. ss of creating signed scripts is somewhat it is done have change between Netscape 4 and re beyond the scope of this book, but you can learn more because most of the security option allowed to control ActiveX objects and Java applets, and whether they can perform paste (as in cut-and-paste) operations. You are not given the option, for example, of disabli the same-origin policy for a trusted site or of allowing scripts from trusted sites to sen email messages without a user confirm Netscape 4 and Netscape 6 implement configurable security with an approach known a signed scripts." Signed scripts provide complete fine-grained configurability of securi compelling. Unfortunately, since Microsoft has no compatible tech creating signed scripts is cumbersome for script authors, and the use of signed scripts can be confusing for end users, the use of this promising tec Briefly, a signed script bears an unforgeable digital signature that specifies the pe ibility for the script. When script needs to circumvent one of the se quests a special "privilege" that allowre As I've already mentioned, the proce mbersome. Also, the details of howcu Netscape 6. Those details a online at http://developer.netscape.com/docs/manuals/signedobj/trust/index.htm and http://www.mozilla.org/projects/security/components/. . times had to release security patches to prevent JavaScript code from exploiting the t the to be private. 21.1 JavaScript and Security JavaScript& apos;s first. JavaScript provides a basic level of security against the most egregious attacks, other security issues remain. These are primarily privacy issues -- JavaScript