The following paper was originally published in the Proceedings of the 7th USENIX Security Symposium San Antonio, Texas, January 26-29, 1998

Security of 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

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 - 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, ,

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, ,

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 :

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

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..

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