The following paper was originally published in the Proceedings of the 7th USENIX Security Symposium San Antonio, Texas, January 26-29, 1998
Security of Web Browser Scripting Languages: Vulnerabilities, Attacks, and Remedies
Vinod Anupam and Alain Mayer Bell Laboratories, Lucent Technologies
For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org/
Security of Web Browser Scripting Languages:
Vulnerabilities, Attacks, and Remedies
Vino d Anupam Alain Mayer
Bel l Laboratories, Lucent Technologies
600 Mountain Avenue
Murray Hil l, NJ 07974
fanupam,alaing@bel l-labs.com
we discovered do es not lead to full system p enetra- Abstract
tion where an attacker can access a user's resources
While conducting a security analysis of JavaScript
les, pro cesses at will. It might thus be argued
and VBScript, the most popular scripting languages
that such aws are less serious. However, security
on the Web, we found some serious aws. Moti-
and privacy concerns see, e.g., cover story of Time
vated by this outcome, we propose steps towards a
Magazine, dated 8/15/97 have b een the single most
sound de nition and design of a security framework
imp ortant barrier to electronic commerce achieving
for scripting languages on the Web. We show that if
its multi-billion dollar p otential. In this light, at-
such a security framework had been integrated into
tacks on a user's security and privacy, are a matter
the respective scripting languages from the very be-
of serious concern.
ginning, the probability of preventing the multiple
Motivated by the ab ove considerations, we pro ceed
security aws, that we and other research groups
to show necessary steps towards a general security
identi ed, would have been greatly increased.
framework for scripting languages on the Web. We
put forward the notion of a safe interpreter. A safe
interpreter must assure:
1 Intro duction
Data Security. Data provided by the user p os-
JavaScript and VBScript are p opular scripting lan-
sibly encrypted b efore it is transmitted can
guages used for Web-page design. A user accessing
only b e accessed by the intended recipient; the
a JavaScript/VBScript enhanced Web-page causes
p ossibility that credit-card data, transaction
scripts to be downloaded onto the user's machine
details, etc. may b e obtained by someone else
and to b e executed by the interpreter of the user's
is highly damaging.
browser. Scripts typically cannot directly access
the user's le-system or the network. This is prob-
User Privacy. Information ab out the user
ably the reason that, in contrast to the Java pro-
should not be given out unless explicitly al-
gramming language, no formal security mo del and
lowed by the user; this protects against un-
hence no explicit rules were ever do cumented on
wanted tracking, identi cation dossiers, junk e-
what is and what is not allowed by scripts. A
mail, surreptitious le uploads, etc.
string of serious security aws discovered by sev-
As a concrete example, we give excerpts from Se- eral research groups, including successful attacks on
cure JS, our prop osal for a more secure version of patches issued to x original aws, shows that this
JavaScript. In this pap er, our treatmentcovers se- is a dangerous omission. In particular, we found
curity issues of scripting languages up to Naviga- aws which allow private data supplied by a user
tor 4.* and IE 4.*. However, we do not address e.g., credit card numb ers, passwords, e-mail ad-
co de signing, a topic that transcends scripting lan- dress, etc in a Web transaction to b e captured by
guages. Also, to day's browser environment allows an attacker. Suchanintrusion works even when a
emb edded scripts to communicate with entities like user employs encryption e.g., SSL, since the data
applets and plug-ins, outside the scripting languages is captured either b efore it is encrypted or after it
prop er, adding a lot to the scop e of what scripts can is decrypted. In contrast to some of the security
do via these entities. This "comp osition" of di erent aws found in Java see [MF97], the vulnerability
entities with di erent security p olicies and frame- from Netscap e Corp. JScript, Microsoft Corp.'s
works is not well understo o d; other safe scripting implementation, is a clone that is interpreted in
environments, such as Safe-Tcl see [B94,OLW96], Microsoft's Web browsers. In the rest of this pa-
do not allow such comp osition. We can only touch p er, we use JavaScript to refer to b oth strains.
up on this issue; a thorough treatmentisbeyond the JavaScript is ob ject-based in the sense that it uses
scop e of this pap er. built-in and user de ned extensible ob jects, but
The notion of a secure op erating system, which pro- there are no classes or inheritance. The co de is
integrated with, and emb edded in, HTML. By de-
vides safe containers for di erentWeb technologies
Java, plug-ins, JavaScript would help in achiev- fault, JavaScript provides an ob ject-instance hier-
ing the ab ove goals. However, we emphasize that archy that mo dels the browser window and some
most of the uncovered vulnerabilities of scripting browser state information. E.g., the navigator ob-
languages originate within the language itself. For ject provides information ab out the browser to a
instance, a rogue site may contain attack scripts script, and the history ob ject represents the brows-
which can access and send back data obtained ing history in the browser window. Also, through a
from other do cuments without any p enetration of pro cess called 're ection', JavaScript automatically
creates an ob ject-instance hierarchyof elements of
the underlying op erating system or concurrent ap-
plication. the script's HTML do cument when it is loaded by
Finally,we show that if our framework had b een de- the browser. The location ob ject represents the
URL of the current do cument, while the document
signed and integrated when either JavaScript or VB-
Script were conceived, the probability of preventing ob ject encapsulates HTML elements forms, links,
the string of security aws, that were identi ed byus anchors, images etc. of the current do cument. This
de nes a unique name space for each HTML page
and other research groups, would have b een greatly
increased. This motivates the need for future de- and thus for each collection of scripts emb edded in
that page. Variable data typ es are not declared,
signs of scripting languages to explicitly consider se-
curity asp ects during initial design. However, secu- i.e., loose typing. Ob ject references are checked at
rity is never absolute. Implementation errors, even runtime, i.e., dynamic binding.
in a sound security design, are not unlikely and can
VBScript see, e.g., [L97] is an application script-
be exploited by an attacker. Such aws, however,
ing language that lo oks a lot like Visual Basic. It
are harder to identify by an attacker.
is lo osely typ ed and ob ject based. It can be used
for scripting Microsoft's browser, Internet Explorer,
Organization of the Pap er: In Section 2 we re-
with whichit communicates using ActiveX Script-
view the basic concepts of browser scripting, and
ing. ActiveX Scripting allows host applications,
brie y intro duce JavaScript and VBScript, the two
like browsers, to compile and execute scripts, and
most p opular scripting languages for Web browsers.
manage the name-space exp osed to the script. The
Section 3 presents the essence of our attacks on
ActiveX Scripting Ob ject Mo del SOM creates an
JavaScript and VBScript capable browsers. We
ob ject instance hierarchy containing, among other
then prop ose, in Section 4, a security framework
things, window, navigator and history ob jects as de-
for scripting languages on the Web. We illustrate
scrib ed ab ove. Also, the location ob ject represents
this framework with concrete notions and examples
the current URL, and the document ob ject re ects
taken from our prop osal of SecureJS. In Section 5,
the current HTML do cument. VBScript scripts are
we discuss our attack in more detail and p oint out
emb edded in HTML do cuments, and are interpreted
how our framework would have help ed in prevent-
automatically when the do cument is loaded.
ing it. Section 6 concludes. In the App endix, we
discuss attacks designed by other groups and again
showhow our framework would have help ed in pre-
venting them.
3 Our Attack
While conducting a security analysis of JavaScript
2 Browser Scripting Languages: An
we discovered a serious vulnerabilityinJavaScript-
Overview
capable browsers. We subsequently analyzed VB-
Script, and discovered that the vulnerability could
b e exploited equally e ectively using VBScript. The
vulnerability in Microsoft browsers was thus also in JavaScript see [F97, KK97] is a simple pro cedu-
the ActiveX Scripting Ob ject Mo del - JScript and ral language that is interpreted by Web browsers
VBScript interpreters are front ends that communi- do cument itself can b e sub jected to analysis, yield-
cate with the underlying ActiveX SOM ob jects. ing information ab out di erent elds, options and
their corresp onding values. Particularly serious is
the fact that this exploit bypasses security provided
3.1 Overview
by secure so ckets or HTTP authentication, since
manyWeb servers and other business platforms are
On the Web, scripts emb edded in multiple browser
administered over the Web nowadays. Information
windows containing do cuments from the same Web
ab out do cument URLs and links on pages can also
site same domain name are allowed to access data
provide the attacker with an idea of how the do-
in each other, in order to supp ort multi-windowed
main is organized. This knowledge may b e used to
user interfaces. Our analysis revealed, however, that
help conduct other attacks. One can envisage a sce-
browser windows could b e tricked into trusting at-
nario where the Tro jan horse actively browses the
tack scripts from rogue sites, thus allowing them to
intranet, p ossibly under remote control from out-
access their data. A rogue site could be set up to
side the rewall, trolling for any and all information
track all Web-related activity of visitors even after
accessible via the browser.
they had left the site, using a Tro jan-horse attack.
The tracking provided access to all data typ ed into
forms, including password elds, co okies, and vis-
ited URLs. The data was extracted right in the
4 The Notion of a Safe Interpreter
browser, so using a secure encrypted connection to
retrieve do cuments didn't accord the user any extra
4.1 Execution Environment
protection. Likewise for users b ehind rewalls - data
was intercepted while in the browser, and transmit-
We consider a networked system. The basic entities
ted to the outside rogue site via a proxy server.
on a single machine in our execution environment
are windows, contexts, scripts, interpreters, name-
3.2 Implications
spaces, and external interfaces. A concrete example
of a window is a browser window. A user can have
This browser vulnerability has a serious implica-
multiple windows op en on her machine at any p oint
tion for Web users. Once infected by the Tro jan
in time. A window and its content e.g., the current
horse, the user's Web interaction is fully exp osed to
HTML do cument displayed de ne a context. When
the attacker - every URL retrieved, all data typ ed
the content of a windowchanges e.g., as the result
into forms - including credit card numb ers and pass-
of loading a new HTML do cument, the window's
words, all co okies set by servers accessed etc.
context changes as well. A script is a co de fragment
The HTTP proto col supp orts a facility for authen-
in a scripting language emb edded in the contentofa
ticating Web users. ManyWeb-based services how-
window. A do cumentmayhavemultiple co de frag-
ever use alternate metho ds of authorization that
ments emb edded in it. All of them share the win-
provide more exibility. These metho ds involve the
dow's context. The content of a window and hence
use of dynamically generated, opaque "session keys"
anyemb edded script is typically downloaded from
emb edded in URLs, in hidden elds of forms or in
aWeb server across the network by the browser. An
co okies. The ability of the attack to access such in-
emb edded script is executed within the window's
formation in an HTML do cument makes all of these
context byaninterpreter. A name-space is the hi-
authentication mechanisms susceptible to compro-
erarchy of ob jects accessible to a script executing
mise.
within the window's context. A script might also b e
This browser vulnerability also has a serious im- able to invoke actions external to its context via an
plication for intranets. Most users use the same external interface. For example, a script can cause
browser to access information on the intranet as well the browser to op en HTTP/FTP connections, send
as the Internet. A user who has b een "attacked" us- e-mail etc. Finally, a script can establish a trust re-
ing this vulnerability has essentially compromised lationship between its context and another window's
the rewall for the duration of the browsing session context, which enables it to access the name-space
- the Tro jan horse is able to extract data from subse- of the other context via a reference. For example,
0
quently loaded intranet do cuments and transmit it Figure 1 depicts three op en windows w , w , and
00
to an external entity. Any data that the user enters w on a user machine, where the scripts execut-
0
into forms - ID numb ers, vendors and prices, bug ing in w 's and w 's context can access each other's
rep orts, passwords and other proprietary informa- name-space and scripts in w can access some exter-
tion can b e relayed to the outside. In addition, the nal interface, giving them additional capabilities. window r r/w i s w w’ context scripts w, w’
N
w’’
Figure 2: Partitioning of the Name-space
implemented. We discuss these comp onents in the
External Interfaces next few sections.
(e.g., Browser, Java)
4.3 Access Control
Figure 1: Execution Environment
The rst task of a safe interpreter is to clearly sp ec-
ify what ob jects are accessible to an arbitrary con-
In some instances, a browser window may contain
text - i.e. what constitutes its name-space. A safe
a framed do cument with multiple frames, which are
interpreter 1 de nes the name-space N of a con-
C
subwindows containing other do cuments. From the
text C , i.e., which ob jects exist at the time C is
p ersp ective of a safe interpreter, each frame in a
activated, 2 the initial values of these ob jects, and
framed do cument is an indep endent window.
3 ensures and implements the following partition-
ing of N :
C
4.2 Safe Interpreter
r
N : Items in the ob ject-instance hierarchy
C
A script loaded into a window in the ab ove execu-
readable by a script in C .
tion environment originates at an arbitrary machine
w
N : Items in the ob ject-instance hierarchy
on the network, and is therefore an untrusted entity
C
readable and writable by a script in C .
on the user's machine. Hence, a safe interpreter has
the task of isolating scripts from executing any un-
s
N : Items created by a script in C .
C
safe commands those that could result in security
compromises if misused, thus implementing what is
i
N : Items created by the interpreter in C .
C
called a paddedcel l in [OLW96]. The interpreter has
We use the term item to describ e either an ob ject,
to implement access control with resp ect to ob jects
within the script's own context. Ob jects containing function, variable, or an ob ject prop erty. Func-
browser or window data for example, should only tions do not need to be treated separately in this
framework - they are executable if they are read-
b e read-accessible. A safe interpreter has to isolate
r
contexts from each other: a user might decide to able. Figure 2 shows the following invariants: N
C
w s i
provide some information in one context to b e sent and N are disjoint, N and N are disjoint. Also
C C C
r w s i i
N [ N = N [ N = N . N is sp ecial
back to a sp eci c machine - this information should
C
C C C C C
not b e accessible to any other machine on the net- in the sense that insertion and deletion of elements
i
into N o ccurs only when the interpreter creates
work, and hence must b e inaccessible to a script in a
C
di erent context. On the other hand, under certain and deletes a context - scripts in an active context
circumstances, scripts in di erent contexts require cannot directly add and remove items from this set.
i
Initial values of some of the items in N dep end on
mutual access, e.g., an application on the user's ma-
C
chine which runs in multiple windows requires the the window, in which the context is loaded and ac-
ability to access data in di erent windows. A safe tivated - the execution environment. It is the role of
the safe interpreter to assure correct initialization.
interpreter must allow this kind of access to scripts
in trusted contexts
In summary, a safe interpreter has to implement ac- Design Issue 1 for Secure JS: De ning the
cess control, independenceofcontexts, and manage- Name-space The rst design issue is to exactly
s i
ment of trust among di erent contexts. Provision de ne N =N [N . The client-side JavaScript
C
C C
for these comp onents do es not realize a particu- environment is de ned by its object instance hierar-
lar security p olicy. Rather, it gives a framework chy - ob jects have properties which may be other
i
in whicha variety of security p olicies can b e easily ob jects. N is roughly equivalent to the entire C
i
JavaScript object hierarchy at the time an HTML and manipulated only in sp eci c ways N . 2
C
do cument is b eing loaded into a window. Every
ob ject created by a script after the do cumentisal-
Design Issue 2 for Secure JS: Read-only
s
ready loaded b elongs to N . The window ob ject is
vs Writable Ob jects We now have to sp ecify
C
r w
the ro ot of the JavaScript ob ject instance hierar-
the partitions N and N . Semantically, cer-
C C
chy. It has a number of prop erties. For example,
tain prop erties of the name-space are unmo di able,
window.name is a string that contains the browser-
e.g., document.lastModified sp eci es the time at
window's name. The window ob ject also contains
which the currently loaded do cumentwas last mo d-
other prop erties such as the window.document ob-
i ed; document.URL contains a string that repre-
ject that contains HTML elements re ected from
sents the URL from which the do cument was re-
r
the current do cument, the window.navigator ob-
trieved. Such ob jects are trivially in N , the read-
C
ject that encapsulates prop erties of the browser
only subset of the name-space. Other prop erties,
software, the window.history ob ject that repre-
suchas document.forms.length etc., that are re-
sents the browsing history in that window etc. All
ected from the loaded HTML do cument should not
of these prop erties are created by the interpreter
b e directly mo di able by scripts, and hence b elong
i
r
when a context is loaded and hence b elong to N .
in N . Ob ject prop erties, like document.domain,
C
C
In contrast, consider the co de fragment var foo;
are used for trust management see Section 4.5 and
r
foo = "bar";. This assignment is equivalent to
should b e in N . The value prop erty of most form
C
window.foo = "bar";, and results in the window
elements is intended to b e mo di able by scripts, and
w
ob ject getting a new prop erty foo, whose value is
thus b elongs to N . However, the value prop erty
C
the string "bar". This prop erty foo of window
of a FileUpload element contains a user sp eci ed
is created by a script after the context has b een
lo cal lename to be transmitted over the network
s
loaded. Consequently, foo b elongs to N .
as part of the form submission. To disallow scripts
C
from setting this prop erty and retrieving arbitrary
r
lo cal les, this ob ject rightly b elongs in N . All ob-
C
jects created directly by a script are writable, and
w
hence in N . One metho d of unauthorized activ-
Explicit sp eci cation of what b elongs to the name-
C
ityinvolves a script covertly passing information to
space regulates what can ever directly b e accessed
another script. This necessarily involves one script
by a script. A more ne-grained sp eci cation of
i
writing a value into an ob ject that is subsequently
what b elongs to N dep ends on the p olicy for User
C
read by another script. By treating writable ob jects
Privacy. For example, document.referrer con-
w
in N more strictly, the interpreter can protect
tains the URL of the do cument from which the
C
against establishment of suchcovert channels. 2
user reached the current do cument. Some of the
prop erties of window.navigator e.g. userAgent
contain information ab out the user's op erating sys- Wehave seen how a safe interpreter assures that N
C
tem. Many privacy-conscious users employ pri- is always disjoint from any private user resources
vacy proxies, such as the Anonymizer see [Anon] on the machine, such as the le system, pro cess
or LPWA see [LPWA] to lter this typ e of in- data, so ckets, etc. This is much like the concept
formation from their HTTP requests. Hence, we of a padded cell in Safe-Tcl [OLW96]. However,
recommend against the inclusion of these items in access to such resources is very useful. In Safe-
i
N and hence in N . The window.history ob- Tcl, such accesses are regulated via a master inter-
C
C
ject contains an array of strings that sp ecify URLs preter, whose metho ds can be invoked by the safe
that have b een previously visited by the user in interpreter. Hence, such access is regulated within
that browser window. In all current versions of the language itself. Unfortunately, for scripting lan-
i
JavaScript, this array is no longer in N by de- guages on the Web, no such master interpreter is
C
fault, to protect against unauthorized access to that available. External interfaces give a script capabil-
s
information by scripts. Note that N contains ob- ities to invoke browser functionality, or metho ds of
C
jects created directly by scripts. From the stand- Java applets and ActiveX scripts. Each suchinvo-
p ointof security and privacy, these ob jects do not cation across interfaces needs to b e examined by the
need to b e protected from the scripts that created interpreter, which has the option of 1 allowing the
them. This semantically splits the name-space into call to pro ceed, 2 ab orting the call, or 3 asking
two disjoint subsets, one that contains ob jects to the user's explicit p ermission for the call to pro-
s
which scripts have largely unregulated access N , ceed. However, the resulting overall security p olicy
C
and one that contains ob jects that can b e accessed dep ends b oth on the p olicy of the safe interpreter
via form.submit. Whenever a proto col sp eci ed in
the URL of the origin server is not HTTP, the safe
terpreter should get a user's approval. SMTP and access in
policy Context of Script
tially reveal a user's e-mail ad- to FTP requests p oten
user
Furthermore, a user mightbebrowsing via a machine External dress.
Interfaces
privacy HTTP-proxy and thus unwittingly lose this
protection when b eing switched to another proto-
col. The safe interpreter must prevent a script from
Browser Plug−In Browser Capabililty Java Applets
directly accessing lo cal les of a user. This includes
any browser related les, such as b o okmarks, caches,
history, etc. A general treatment of external inter-
faces with Java, plug-ins etc. is b eyond the scop e
User
this pap er - it requires an understanding of the
Machine Files Sockets of
very general issue of comp osition of security p olicies.
2
Figure 3: External Interfaces
4.4 Indep endence of Contexts
and the p olicy of the external interface, the latter
To ensure indep endence of di erent contexts, the
b eing b eyond the control of the safe interpreter.
following restrictions have to b e enforced by a safe
For example, Figure 3 presents a situation, for
interpreter:
JavaScript, in which scripts can access the browser,
w s
Java applets, and browser plug-ins through exter-
For each active context C , N and N must
C C
0
nal interfaces. As a result, a script can alb eit indi-
0
b e disjoint from N of each other context C .
C
rectly access the le system or the network, making
If an active context C is terminated and a new con- HTPP, FTP, and SMTP requests via the browser.
0
Hence, the overall access security p olicy with re-
text C is loaded and activated in a window w , a
safe interpreter has to do the following op eration in sp ect to these resources dep ends, b esides the safe
N in order to transform it into the initial name interpreter, on the p olicies for the browser, for ap-
C
0 0
space N such that the name space N do es not plets, and plug-ins. For example, if a new metho d
C C
dep end in anywayon C see also Figure 4: is intro duced for applets to access a le and the safe
interpreter remains unchanged, then a script invok-
i
Remove and rebuild N : The set instance hi-
C
ing this new metho d might not b e sub jected to an
erarchy is deleted and rebuilt according to the
appropriate checkby the safe interpreter. What is
newly loaded HTML do cument. This pro cess
really needed, is sound semantics for composition
must ensure that while rebuilding, each item in
of security p olicies. This is an area hardly inves-
w
N is set to a neutral value null.
C
tigated and understo o d at the time of this writing
and is beyond the scop e of this pap er. A safe in-
s
Delete N : remove all its items.
C
terpreter therefore should minimize the number of
accepted external interfaces and their metho ds of-
Invalidate al l references to N within other
C
fered to scripts. Furthermore, it should adopt a con-
contexts, which have b een established by a
servative p olicy for every invo cation of a call across
trust relationship see subsequent section.
an external interface, as well as external accesses to
the script's name-space. A secure op erating system
Design Issue 4 for Secure JS: Indep endent
providing safe containers and interfaces for di erent
Browser Windows A safe interpreter must ensure
applications Java, plug-ins, etc is an alternative.
that the memory of the ob ject hierarchy that cor-
w
resp onds to N is disjoint for di erent windows. Design Issue 3 for Secure JS: Access to Ex-
C
This includes ob jects like the window.navigator ternal Interfaces In order to b e useful, JavaScript
ob ject, which might represent the same browser in- needs, at the very least, an interface to browser ca-
stance for all windows. Enforcing disjointness pro- pabilities to access the network and sp ecial les.
tects against the establishment of covert channels User supplied data in forms need to b e transmitted
between scripts. As describ ed earlier, one metho d back to an origin server. A script cho oses the origin-
of unauthorized script activity involves a script server URL via form.action and the SUBMIT
covertly passing information to another script by metho d via form.method, and submits the user data
example, the co ordination of information in multi-
I S
ws when presented to a user. In order to
N ple windo
maintain a secure system, we need to sp ecify 1
when a script in context C is allowed to establish a
Remove & Delete 0
text C and 2 the subsequent
Rebuild relationship with con
0
privileges for N issued to scripts in C and vice
C
versa.
Initial N’ I’
0 0
If context C in window w trusts C in window w ,
0
then access to C 's name-space is allowed. The safe
interpreter provides scripts in context C with a ref-
Figure 4: Indep endence of contexts loaded into same
0
erence to context C . Via this reference, a script in
window
r
C can read all items in N , read and write all items
0
C
w s
in N and insert items into N . Note that the
0 0
C C
sp eci cation in Section 4.4 implies that if a script
writing a value into an ob ject that is subsequently
s
in C inserts an ob ject into N , this ob ject will only
0
read by the other script. This is particularly rele-
C
0 0
b e accessible to C as long as C is activein w . After
vant for items whose value p ersists across do cument
0
that, C 's reference to C is set to null. We can ex-
retrievals, e.g., some prop erties of the window ob-
w
tend this approach to di erent trust relationships of
ject. By treating writable ob jects in N more
C
0
various degrees: 1 Read-only access to C 's name-
strictly, the interpreter can protect against such
0
space. 2 Access only to ob jects in C 's name-space
covert channels. Secure JS do es not allow values
0
w
which are not declared private by C . The second
of items in N to p ersist when the current do cu-
C
approach requires that each ob ject have a prop erty
ment is unloaded. For example, window.name is a
private which, when set, makes the ob ject invisible
string that sp eci es the name of the browser win-
to external scripts.
dow. If scripts write a value into this prop erty of
the window, then anychanges will disapp ear when
Global Access Control List. A script in context
the current do cument in the window gets unloaded.
C requests to establish a trust relationship via either
2
a open or connect function call to its interpreter.
The safe interpreter then has to decide if such a
Design Issue 5 for Secure JS: Garbage Col-
relationship is p ermissible. This decision dep ends
lection From the ab ove discussion it follows that
on the access control policy. We make use of access
garbage collection based on simple referencecount-
control lists ACL. ACLs are a well-known to ols
ing is not sucient to ensure security since it will not
for implementing secure op erating and le systems.
collect all ob jects that should b e collected. When-
In our mo del, an ACL is a set of contexts. For
ever a do cument is unloaded, the safe interpreter has
example, an ACL can b e a set of URLs, where each
to traverse the entire ob ject hierarchy: Each item in
URL represents a window's current content. We
s
N must be deleted. E.g., the co de fragment var
C
asso ciate with each context C a single access control
i; i = 0 creates an item window.i, which must
list ACL, which indicates the set of contexts which
i
b e removed. Appropriate items in N are deleted.
C
have the privilege to obtain access to N . The ACL
C
w
Each remaining item in N must b e set to a neutral
C
is part of N and its value is loaded whenever C is
C
value, even if it is ab ove the document ob ject in the
loaded into a window. The ACL should only reside
r
hierarchy. E.g., window.status and window.name.
in N ; otherwise, a script, p ossibly from a di erent
C
All references contained in other windows that p oint
context, can change the ACL.
to ob jects in the current windowmust b e invalidated
Let us now de ne the open and connect func-
see also next section, even if the current window
tions:
remains op en and thus window.closed would be
0
A script in C issues openC', w', where w is
false, if the window reference remained valid. 2
a new i.e., not currently op en window: If C
0 0
is in C s ACL, then a new window w is cre-
4.5 Management of Trust
0 0
ated and context C is activated in w ; a trust
relationship is established.
While most contexts are typically indep endent, cer-
0
A script in C issues openC', w', where w is an tain applications greatly b ene t from establishing
00
op en window with an active context C p os- mutual trust relationships among contexts in di er-
00 0 0 00
sibly C = C : If C is in C s ACL, then C ent concurrently active windows. This allows, for
0
ACLs, it allows that "the right to exercise access is terminated and C is activated; a trust rela-
carries with it the right to grant access" as noted in tionship is established.
the context of "unmo di ed" capability systems in,
0
A script in C issues connectC', w': If C is
e.g., [B84, G89a, KL87]. For example, if a script
0
already active in window w , a trust relation-
0
in context C is allowed to read and hence copy
ship is established; otherwise it is handled like
an ob ject in context C , then every script which is
an open call.
00 00 0
in a context C , such that C is in C 's ACL, can
read this ob ject. For more sensitive information,
such transitivity of trust might not b e suitable. For
Design Issue 6 for Secure JS: Global Access
0
instance, bugs in the design of C can lead to unin-
Control Weintro duce the prop erty document.ACL,
0
tended values of the ACL of C , which then allows
the do cument's access control list to be a member
00
scripts of an adversarial context C to access data
r i
of N and N . In Secure JS, window.open imple-
C C
in C , undetectable to C . Many extensions to capa-
ments the open function describ ed ab ove. The re-
bility systems have b een prop osed to address this
quired inputs are a URL and a name. The safe inter-
concern see, e.g., [G89b, KH84, KL87]. In our en-
preter checks that document.domain in the context
vironment, the following simple re nement of the
of the calling script is included in document.ACL of
ab ove access list based control is sucient: Besides
the context de ned via the URL to b e loaded. If
a context-global ACL, each ob ject in this context
this check succeeds, then the interpreter pro ceeds
is asso ciated with its own, lo cal ACL the same as
0
as follows: If name matches an op en window w ,
the global ACL when the context is loaded. In
0
then the current do cument context in w is un-
the realm of secure op erating systems, the data plus
loaded and the new context URL is loaded. If
its data security attributes is called a segment see,
there is no match with an op en window, then the
e.g., [KL87]. When an ob ject gets copied from
0
interpreter op ens a new window w with name and
one context to another, the segment remains in-
loads the the new context URL. If the access con-
tact, i.e., the safe interpreter copies the ACL as well.
trol check is p ositive, window.open returns a ref-
The open and connect routines work as describ ed in
0
erence to the context in w . The safe interpreter
the rst solution; however, if a relationship is estab-
0
also checks if document.domain of w is included
lished, scripts in N get a reference only to those
C
in the calling script's document.ACL.If this check
0
items in N , for which C is in their lo cal ACL.
C
is p ositive, then a side e ect of the this function
Hence, a script's context now plays the role of its
0
call is that w'.opener provides w with a refer-
capability see [KL87], whichischecked against the
ence the calling script's context. We also intro-
ACL of the segment of the item made accessible. A
duce a new metho d window.connect with the same
lo cal ACL of a segment is not part of the scripting
arguments as window.open. This metho d di ers
language prop er and consequently should b e physi-
from window.open only in the case where a win-
cally stored within the safe interpreter, inaccessible
dow with name name and context URL already
to any script. Segments copied from a di erent con-
exists. In that case connect simply provides the
text mighthave a di erentACL. With this security
two contexts with references to each other. Lastly,
0
p olicy, bugs in context C no longer allow access of
we intro duce the new ob ject prop erty private.
third parties to context C .
For Secure JS, each ob ject in the ob ject hierar-
A somewhat dicult asp ect of the scheme describ ed
chy has this additional prop erty. If this prop erty
ab ove, is to unequivo cally de ne the semantics of
is set to true, the corresp onding ob ject is invisi-
"copying" an ob ject, which guides when the ob ject's
ble to external scripts. After executing victim =
ACL has to b e up dated. Assignments are straight-
window.open"www.vendor.com", "spy", and
forward. Many scripting language allow control ow
passing the ACL check a script might try snoop =
constructs, such as if ... then ... else or while ...
victim.document.forms[0].elements[0].value,
do. If a conservative p olicy is assumed, then assign-
assuming that in the victim-context, the rst eld
ments made in the scop e of a control ow construct
in the rst form asks the user for a credit-card num-
should b e considered to b e "copies" of values read
b er. If that eld was sp eci ed to b e private, then the
in the control part. This is similar to, for example,
safe interpreter would not execute the ab ove state-
the tainting facility of PERL see [WCS96].
ment. 2
Design Issue 7 for Secure JS: Lo cal Access Lo cal Access Control List. While the ab ove ap-
Control If Secure JS is used with the option of lo cal proach implements a reasonable trust security p ol-
access control, then every ob ject in the JavaScript icy not unlike a UNIX le system enhanced with
0 0
ob ject hierarchy has a prop erty ACL, its lo cal access scripts in a di erent context C ,ifC is in C 's ACL.
control list. Once again, ACL prop erty b elongs in Scripts in any other context however, are not able
r i
N . When a context is loaded and items in N to access this data. Furthermore, setting the private
C C
are created, the value of their resp ective ACL prop- prop erty of an ob ject guarantees that only scripts
erty is set to the value of window.document.ACL. of the same context can access that ob ject. This
s
Items created by scripts and hence in N also is assured by trust management. Independence of
C
0
have the same initial value of their ACL.Now con- contexts assures that any context C activated after
sider the example, where a script in context C exe- C in w cannot access any data written in C . Fur-
00 0
cuted window.open which returned a reference vic- thermore, if C had a reference to a context C that
0
tim to another window context C . The script can was loaded in w b efore C , this reference was set to
0
now execute the following co de: creditCardNum = null at the time C was unloaded; assured by inde-
victim.document.forms[0].elements[0].value p endence of contexts. Hence, only scripts in trusted
assuming that the rst element of the rst form contexts can access the user input data. Accesses to
0
of context C asks the user for a credit card num- user data by external interfaces are guarded by the
b er. A side e ect of this co de is the assignment safe interpreter.
creditCardNum.ACL = victim.document.ACL.
The script in C now executes window.open again
to op en another window with a third context
5 Security Analysis
00 00
C . A script in C could p otentially execute
In this section, we discuss scripting languages vul-
snoop = window.opener.creditCardNum. How-
nerabilities exp osed by di erent attacks, highlight-
ever, b efore this co de is executed, the safe in-
00
ing how they could have b een prevented using a safe
terpreter veri es that C 's document.domain is
interpreter. We discuss other variants of this attack,
included in window.opener.creditCardNum.ACL,
as well as other problems with JavaScript in the Ap-
p ermitting the op eration only if the check succeeds.
p endix.
2
5.1 Bell Labs Attack
4.6 How the pieces t together
Our security analysis of scripting languages on
In this section, we brie y showhow the concepts of
browsers from Netscap e Corp. and Microsoft Corp.
access control, indep endence of contexts, and trust
that are currently in use revealed that browser win-
management supp ort data security and user privacy.
dows could be tricked into trusting attack scripts
User Privacy: Almost all data on a user's ma-
from rogue sites, thus allowing them to access
chine which is not directly related to the current
their data and hence the name-space of emb edded
HTML do cument should be considered private to
scripts. See [CERT97, NN-Bug97, MSIE-Bug97].
a user. Access control provides a padded cell for
Using this vulnerability, a rogue site could be set
scripts, which assures that scripts cannot access the
up to track all Web-related activity of visitors even
le system, pro cess data and other unsafe resources.
after they had left the site, using a Tro jan-horse at-
By maintaining a clear separation of data outside
tack. The tracking provided access to all data typ ed
a name-space, read-only items, and writable items
into forms e.g., password elds, to co okies, and to
within the name-space, access control assures that
visited URLs.
scripts only have access to those parts of browser
There were three requirements for the Tro jan horse
and window related data, which do not compromise
to successfully sno op on user activity. It needed
a user's privacy while browsing. We have also de-
to p ersist across multiple do cument fetches script
scrib ed the external interface to a browser. Further-
context changes, it needed to b e able to access data
more, independence of contexts assures that there
from other loaded do cuments across windows, and
are no "hidden channels" among di erent contexts.
it needed to b e able to transmit captured data to a
For example, if a writable item p ersisted across
desired lo cation. A 'safe interpreter', prop erly im-
changes of context as it is currently the case in
plemented, would have safeguarded against all those
JavaScript, it could b e used as a user-invisible al-
attack comp onents.
b eit non-p ersistent 'co okie' accessible to collab o-
rating Web-sites.
5.2 Initialization
Data Security: Data provided by a user in a con-
Initially, the user loads an HTML do cument con- text C of a window w e.g., by lling out a form in
text C into a browser window w , which unknown the context's HTML do cument is only available to
to the user contains some adversarial script. This Navigator 2.* and 3.*. In the case of Navigator 4.*,
script rst sets itself up to exist indep endently of the data was extracted by writing to and reading from
original window w , so it can p ersist across multiple a prop ertyofamutually accessible ob ject. Hence,
0
do cument loads in w . To do this, it creates a new the contexts of these two windows w and w were
window subsequently called the sno oping window not disjoint!
0
w using a window.open call, and loads a di erent
0
HTML do cument context C that contains the at-
0
tack script into w . Though a vigilant user could
Microsoft Internet Explorer
notice the presence of the new window, the creation
of a new window is not a suspicious act in itself-
Microsoft Internet Explorer 3.* did not imp ose any
many sites use multiple windows to display do cu-
security restrictions that needed to be bypassed.
ments on the Web. In addition, control over size,
Starting with the window reference of the observed
placement and stacking of windows can b e used ef-
window w , attack scripts in the sno oping window
fectively to reduce the chances of detection.
0
w were free to walk the instance ob ject hierarchy
of the observed window w , and had direct access to
5.3 Data Extraction
all the information in any do cuments subsequently
0
loaded into the observed window. The attack scripts
The attack script in w next gets a handle ob ject
p erio dically p olled the current context C of the ob-
reference to window w . In Netscap e Navigator 2.*,
served window w for its contents, copied the data,
this is done by setting a prop erty of the sno oping
0
and then transmitted the captured data to a remote
window w when it was created by the adversarial
server.
script in window w . In all other browser versions,
We subsequently discovered that the same e ect
the window.opener prop erty of the JavaScript ob ject
0
could b e achieved using VBScript. This variantof
window gives the attack script in window w the
the attack scripts used VBScript to set up a sno op-
desired reference to w . We discuss more sp eci cs of
0
ing window w , whichwas subsequently able to walk
the vulnerability and the attack in the context of
the instance hierarchy of the observed window w ,
di erent browsers, highlighting the de ciencies that
and capture and transmit all the information.
were exploited.
The b eta version of Microsoft IE 4.0 also has a se-
Netscap e Navigator
curity mo del centered around script address based
access control. Once again, the exploit bypassed
Navigator 2.*, 3.*, and 4.* all use various means of
securityby using JavaScript URLs to inject and ex-
trust management: 1 do cument address based ac-
ecute arbitrary JavaScript co de in the observed win-
cess control - only a script from the HTTP server
dow, and to move captured data from the observed
domain name that sent the HTML do cument is
window to the sno oping window.
able to access data in a do cument, 2 a Perl-like
'tainting' mo del [WCS96, F97, KK97], and 3
a digital signature based scheme for access control
5.4 Data Transmission
[KK97], in which only signed scripts with the appro-
priate rights are able to access data in do cuments
Once data was obtained, scripts in the sno oping from other domains.
0 0
window w were free to transmit it to a lo cation The attack script in window w bypassed secu-
of their cho osing. They could transmit directly via rity in all cases by using the window reference
HTTP by sending the data to a dynamically con- to insert arbitrary scripts into the observed win-
structed URL. This could not be detected by the dow w 's context in the form of JavaScript URLs
user. The sno oping window could put the data into These are URLs of the form javascript: elds of a form and automatically submit the form. code>. We discovered that co de in these JavaScript This metho d could be detected and circumvented URLs was not sub ject to access control and p er- by a vigilant user who had set up the browser to sisted across do cument reloads context changes in require interactive con rmation of all form submis- w . The inserted scripts p erio dically gathered all sions. Finally, co de in the sno oping window could information available in the current context of the communicate with an installed Java applet and/or observed window w , and made it available to the 0 ActiveX script to transmit the information to a de- sno oping window w . Data was stolen by directly sired lo cation. This also could not be detected by writing into prop erties of the sno oping windowdoc- the user. ument from the observed window, in the case of Conference on Upp er Layer Proto cols, Archi- 5.5 Role of a Safe Interpreter in the Bell tectures, and Applications, 1994. Labs Attack [B97] D. Brumleve, Tracker Privacy Bug, Aleph2 The safe interpreter describ ed in Section 4 would Software, July 1997, http://www.aleph2.com/ have protected against this style of attacks. When tracker/tracker.cgi. the attackwas set up, context C in w , the observed 0 0 window, and context C in w , the sno oping window, [C97] K. Chiang, Singapore Privacy Bug, ITI, Sin- trusted each other, since they b oth originated on gap ore, July 1997, http://www.iti.gov.sg/ the attacker's Web-site. Prop er trust management iti p eople/iti sta /kcchiang/bug/. would have terminated the trust relationship when C was unloaded from w - trust do esn't p ersist across [CERT97] CERT* Advisory CA-97.20, JavaScript unloading of HTML do cuments context changes. Vulnerability, CERT Co ordination Center, July The contexts would have b een prevented from writ- 1997, ftp://info.cert.org/pub/cert advisories/ ing into each other. Enforcement of indep endence of CA-97.20.javascript. contexts by the safe interpreter would subsequently 0 have disallowed any accesses from C to C and vice [F97] D. Flanagan, JavaScript: The De nitive versa via the reference to C , rendering it useless Guide, O'Reilly and Asso ciates, January 1997. for tracking. Finally, a regulated external interface could have b een used to implement p olicies that [G89a] L. Gong, On Security in Capability-Based alerted the user to p otentially suspicious activity Systems, ACM Op erating Systems Review, when the safe interpreter detected that an attempt 1989. was made to send data from a di erent site to the [G89b] L. Gong, A Secure Identity-Based Capabil- attacker's machine. ity System, IEEE Symp osium on Security and Privacy, 1989. 6 Conclusions [G97] L. Gong, New Security Architectural Direc- tions for Java, IEEE COMPCON, 1997. We have shown how taking steps towards a care- ful security design for scripting languages can help [JRP96] T. Jaeger, A. Rubin, A. Prakash, Build- in preventing successful attacks on a user's se- ing systems that exibly control downloaded ex- curity and privacy on the Web. It is not sur- ecutable content, 6th USENIX Security Symp o- prising that well known notions in access con- sium, 1996. trol, such as \ACL" and \capability" see, e.g., [B84, G89a, G89b, KL87] reapp ear, not only in [KH84] P. A. Karger, A. J. Herb ert, An augmented our context, but also in ongoing research on how capability architecture to support lattice secu- to design a more exible Java downloaded ex- rity and traceability of access, Pro c. 1984 IEEE ecutable content security architecture see, e.g., Symp. on Security and Privacy. [JRP96, G97, WBDF97]. It demonstrates that for a sound security mo del for downloadable, exe- [KK97] P. Kent, J. Kent, Ocial Netscape cutable content on the Web, there are no shortcuts JavaScript 1.2 Book, Netscap e Press & Ven- to a careful design based on notions and algorithms tana. develop ed for secure op erating systems. [KL87] R. Y. Kain and C. E. Landwehr, On Access Checking in Capability-Based Systems. IEEE Transactions on Software Engineering, Vol SE- References 13,No2,February 1987. [Anon] Anonymizer, http://www.anonymizer.com. [L96] J. R. LoVerso, JavaScript Security Flaws, [B84] W. E. Bo eb ert, On the Inability of an Un- OSF, http://www.osf.org/ loverso/javascript/. modi ed Capability Machine to Enforce the *- [L97] P. Lomax, Learning VBScript, O'Reilly and Property, 7th DoD/NBS Computer Security Asso ciates, July 1997. Conference, 1984. [B94] N. Borenstein, Email with a mind of its own: [LPWA] Lucent Personalized Web Assistant, The Safe-Tcl language for enabled mail, IFIP http://lpwa.com:8000. [MF97] G. McGraw and E. Felten, Java Security: A safe interpreter would not allow scripts of an un- 0 Hostile Applets, Holes, and Antidotes. Wiley trusted context C to insert co de into context C , Computer Publishing, 1997. thus disallowing subversion of the onUnload event handler. [MSIE-Bug97] Bel l Labs Privacy Problem, Mi- crosoft Corp., July 1997, http://www. Singap ore Attack microsoft.com/ie/security/b ell.htm. Another similar attack was devised indep endently [NN-Bug97] see [C97] and worked sp eci cally in Netscap e Nav- Bel l Labs Privacy Bug, Netscap e Corp., July igator 4.*. It was even more insidious. This Tro- 1997, http://www.netscap e.com/assist/ jan horse did not use a separate window to p er- security/resources/b ell labs privacy.html. sist across multiple do cument fetches, and was thus harder to detect. The JavaVMinbrowsers allows [OLW96] J. Ousterhout, J. Levy, B. Welch, The applet threads to continue to run even after the do c- Safe-Tcl Security Model, Manuscript. ument that started the applet is unloaded. A dis- cussion of Java and its security is outside the scop e [S97] A. dos Santos, Santa Barbara Privacy Bug, of this do cument, see, e.g., [MF97]. LiveConnect UCSB Secure Internet Programming Team, [F97] is a 'glue' technology from Netscap e Corp. August 1997, http://www.cs.ucsb.edu/ andre/ that is designed to allow Java applets, browser Attack.html. plugins and JavaScript scripts to communicate in Netscap e's browsers. It is manifested as an API [WBDF97] D. Wallach, D. Balfanz, D. Dean, E. Fel- that programmers can use to implement desired in- ten, Extensible Security Architectures for Java. teraction b etween these di erententities. An applet Princeton CS, TR-546-97, April 1997 can communicate with scripts by using LiveConnect Java classes to get a window handle reference to [WCS96] L. Wall, T. Christiansen, R. Schwartz, aJavaScript context. The attack applet obtained Programming Perl. O'Reilly & Asso ciates, Inc., a window handle of its own window w , which re- Septemb er 1996. mained valid even after the HTML do cument C that initially loaded the applet was unloaded, and an- 0 other HTML do cument C was loaded into the win- App endix: Other Attacks dow. The applet could then, via the window handle, walk through the JavaScript ob ject instance hier- In this section we describ e some of the other browser archy of the new do cument, access any contained scripting language based attacks that were rep orted. information, and transmit it to a remote server. A safe interpreter would invalidate the reference to a The Tracker attack context C including references given to external in- terfaces as so on as C was unloaded and thus would An attack that b ehaved similar to the Bell Labs at- prevent the Singap ore attack. This attackhowever, tack, and worked sp eci cally in Netscap e Navigator is a reminder that interaction b etween di erent en- 3.0 was devised indep endently, see [B97], and was tities with di erent security p olicies is not well un- equally e ective at monitoring user activityonthe dersto o d and always a p otential threat. Web. It worked even for Navigator 3.02, which in- This p oint was further substantiated by the Santa corp orated a patch for the Bell Labs attack! The Barbara attack see [S97], which pro duced similar onUnload event handler for do cument ob jects is a results in Netscap e Communicator 4.02. It used a piece of JavaScript co de that is executed when the Java applet to access and steal data in HTML do c- browser unloads the current HTML do cument be- uments in an observed window W by tricking it into fore replacing it with a new do cument. This attack executing attackJavaScript co de. worked by using attack scripts in an attack win- 0 dow w context to dynamically insert a new onUn- Other Scripting Attacks load handler in the observed browser window w . From the start, JavaScript implementations inad- This newly inserted co de would b e activated when vertently allowed malicious scripts to attack a user the current do cument C was unloaded, and would in di erentways [L96]. walk through the ob ject instance hierarchy and sur- Early implementations of JavaScript stored the reptitiously transmit all accessible information to a user's browsing history into the history ob ject, and remote server. allowed scripts read-access to the whole ob ject. Ma- le would be transmitted to the Web server when licious scripts were free to transmit this informa- the form was submitted, either automatically by tion to a server, allowing op erators to trivially build JavaScript or as a result of a user-initiated submis- dossiers on Web users. Another problem, discovered sion. early on, was the complete absence of access control! The recently rep orted French Privacy Bug in This allowed malicious scripts to actively and eas- Netscap e Communicator 4.02 allowed a malicious ily track a user's browsing history by monitoring script to read and transmit a user's lo cal browser another browser window. Avariant of this metho d preferences le if the script could successfully guess allowed scripts to browse directories in a user's ma- it's lo cation on the lo cal le-system. The Freiburg chine by starting with a do cument obtained via a Issue a ected Microsoft Internet Explorer 4.0, and URL using the le: proto col - the script could walk allowed a script to read and transmit lo cal text, through the instance hierarchy of a dynamically gen- HTML or image les if the JScript or VBScript erated do cument that represented the directory and script could successfully guess their lo cation on the its contents from the lo cal le system, and transmit le-system. this information to a remote server. In another in- Though most of these aws were xed as scripting stance, the interpreter let scripts from one do cument implementations evolved, a formal sp eci cation of context stay residenteven after the do cumentwas a safe interpreter or safe interaction with a browser unloaded, op ening the do or to variants of the ab ove vis-a-vis scripting has not b een develop ed and pub- attacks. licly released. Access control in the safe interpreter formally sp ec- Browsers b egan to supp ort the mailto: proto col for i es what a script is allowed to access in the user's submitting forms on the Web, which used the E- environment - hence p olicies on access to history mail infrastructure for transp ort, instead of HTTP. information, user information, les etc. can eas- Automatic submission of forms by scripts, using the ily be implemented. Regulated external interfaces mailto: proto col and hence, the browser as an ex- can be used to implement p olicies that safeguard ternal interface allowed Web-site op erators to sur- against surreptitious capture of information via reptitiously capture the email address of users. File HTTP, FTP and SMTP, or from the le-system. Upload elements in HTML-forms provided a mech- Finally, the formalism of a safe interpreter enables anism for Web users to transmit or upload les one to reason ab out browser scripting at the level of from the lo cal le system to a remote Web server. semantics, rather than mechanics of di erent op er- Malicious scripts, however, were able to sp ecify the ations. absolute path of an arbitrary le, and cause the browser again as an external interface to automat- ically submit the form, transmitting the contents of that le to the remote server. The x for these problems typically involved hob- bling the resp onsible feature - scripts were no longer allowed to access the list of URLs in the history ob ject; a script-address based access control p ol- icy was develop ed - JavaScript scripts could read prop erties of a do cument only if the scripts were loaded from the same server domain name as the do cument; automatic submission of forms using the mailto: proto col was disallowed; and File Upload elements in forms could have their value set only interactively, not bya Web-site op erator. An insidious variant of the File Upload attackwas later discovered in Netscap e browsers. It exploited an obscure bug in the implementation of JavaScript that allowed an attack script to assign an arbitrary le name to a File Upload element of a form. An implementation of this attack violated a name-space rule of the safe interpreter by adding elements to i N , the interpreter-created ob ject set, after the C context C was already activated! The sp eci ed