JavaScript Security

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
and
/>