JavaScript Security

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

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 c

In

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

! 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

! 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

! 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

! Thevalue 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

! 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

! 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

! 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

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

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

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 allow

re

As I've already mentioned, the proce

mbersome Also, the details of how

cu

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/