TeamJava Forum

[ Read Responses | Post a New Response | Return to the Index ]
[ Previous | Previous in Thread | Next ]

JavaScript Security Improvements

Posted by mgmt on Tuesday, 15 July 2003, at 10:32 a.m., in response to security of java, posted by Abeer on Tuesday, 15 July 2003, at 7:55 a.m.

JavaScript security improvements

Edmond Woychowsky, | 30 April 2003

JavaScript has a reputation as an insecure language, but it may not be as bad as some

developers think. Find out the issues and see how maturity has eliminated some of the earlier


Although JavaScript has had its share of security concerns, many of those issues were

addressed and resolved early on. In fact, JavaScript security has steadily progressed, with items

such as excluding support for certain capabilities, restricted features, the "same origin" policy,

security zones, and signed scripts. The main exception to this progress was Netscape

Navigator's past experiment with the data tainting security model. Let's take a look at how these

features contribute to JavaScript's security improvements.

Browsers have different security holes

JavaScript security isn't really troubled by its cross-browser and cross-platform nature. With some

modifications, a script that runs on Internet Explorer on a Mac will also run on Netscape on a PC.

However, the original diversity of platforms and browsers, which were once a real pain to develop

for, also means that the individual browsers don't usually have the same security holes. So the

odds are that while a malicious script may cause problems on Netscape, it will fail on Internet

Explorer, Opera, and Mozilla.

Today, because of the prevalence of a single browser, it's a little like having every farmer in a

country raising the same variety of the same crop. A single disease could conceivably wipe out the

entire harvest for that year and plunge that country into famine. That's a somewhat simplified view,

but consider that a script that executes on my wife's Dell with Windows XP will run on her mother's

XP with Windows 98 and on my Toshiba with Windows 2000 Server. Fortunately, although it may

seem to the casual observer that JavaScript is completely lacking in security features, that isn't the

case; JavaScript does in fact have a limited number of security features.

The data tainting security model

Netscape Navigator 3 introduced the short-lived concept of data tainting. When enabled, data

tainting allowed one browser window to see the properties of another window regardless of what

server the window was loaded from. The author of the second page needed to mark which

properties where tainted and therefore could not be passed on to a server. Although it was an

interesting idea, it required defensive coding, and the client had to enable data tainting.

You can't get there from here

One important part of client-side JavaScript's security is that there are a number of things you just

can't do. There are no objects with which to access the client's files, interrogate the client's

network connections, execute operation system commands, or execute programs. At times, this

lack of certain features can be annoying, but it prevents a world of problems.

Restricted features

Anyone who has recently tried to execute a self.close() on the parent browser window knows that

JavaScript will in fact try to stop some malicious code. When the Web was young and JavaScript

was new, some individuals amused themselves by closing a visitor's browser windows. After a

few months of that, self.close() on the parent browser window became a restricted feature.

There are, in fact, a number of restricted features covering the spectrum of JavaScript features.

They include accessing the browser's history collection, uploading files, submitting, mailing,

altering menu bars, and opening windows that are less than 100 pixels on a side, which could go

unnoticed by the user.

Same origin policy

A script is permitted to read and alter the properties only of documents that have the same origin.

This same origin policy also covers both the port and the protocol. So if a script's origin port is 80

and the protocol is HTTP, switching to port 21 and FTP is not permitted. The logic behind this

restriction is to prevent theft of information. Let's say that I'm a bad guy. If the origin restriction

didn't exist, as long as my script was running, I could take any information entered in another

browser window and send it to my Web site using XMLHTTP or another method. Of course, most

of the information would be useless, but occasionally I would strike gold and get a credit card

number. Talk about your data mining!

The origin security restriction applies not only to documents but also to the browser's cookie

collection. This prevents the bad guy from copying cookies that identify an online shopper to the

shopper's own browser and thus become, in the eyes of the shopping site, that shopper.

Enabling a nice shopping spree--with no pesky bills

With most policies, there are exceptions, and that's true of the same origin policy. The policy

doesn't apply to a script with the UniversalBrowserRead privilege. Scripts with this privilege are

allowed to read properties of documents with a different origin. The UniversalBrowserWrite

privilege permits scripts to write properties. The ability to read and write properties with a different

origin can be obtained through the use of both privileges or through the use of the

UniversalBrowserAccess privilege.

Zones and signed scripts

Microsoft Internet Explorer and Netscape Navigator each have their own method of handling

security. Internet Explorer handles it through the use of zones. With Internet Explorer version 5.5

these zones are Internet and Local Intranet, along with Trusted Sites and Restricted Sites. These

four classifications allow the user or an administrator to set, with a degree of granularity, what

JavaScript can and cannot do by the zone. Somewhat finer control is available by specifying

security on a site-by-site basis. It is important to remember that Internet Explorer doesn't use

security to relax restrictions; it uses it to further restrict capabilities.

Netscape Navigator, on the other hand, administers security using a digitally signed script. This

gives individual scripts the ability, pending user approval, to relax restrictions to various JavaScript

features on a feature-by-feature basis. Although signed scripts are an interesting approach to

security, they do not guarantee that the script isn't malicious. A signed script merely establishes

identity, and even then it isn't a guarantee of identity.

One JavaScript security feature is common to all browsers. On the browser, JavaScript, like Java,

runs in a "sandbox." In essence, when on the browser, JavaScript has restricted capabilities on

the client. Regardless of what people say, without user intervention, JavaScript cannot reformat

your hard drive, change the contents of files, or make your cat go bald. To accomplish anything

outside the sandbox, it is necessary to go beyond the browser.

No more growing pains

The majority of JavaScript security issues occurred in the past, when browsers, JavaScript, and

the Web were all new and experiencing growing pains. As JavaScript and browsers mature, the

security risks have begun to diminish.,2000034810,20274092,00.htm


Post a New Response

Please select: Discussion Question Answer
Pulse Check - enter num: 1060025115

Your Name:

E-Mail Address:



If you'd like to include a link to another page with your message,
please provide both the URL address and the title of the page:

Optional Link URL:

Optional Link Title:

If you'd like to have the option of deleting your post later,
please provide a password (CASE SENSITIVE!):



The TeamJava Forum is maintained with WebBBS 2.24.

TeamJavaHome | Ind. Registry | Co. Registry | Java Links
Jobs Listings Forum | TeamJava Books | Java FAQ Archives


Copyright © 1995-2003 Active Web Networks, all rights reserved.
(Note: We share no direct association with Sun Microsystems, Inc.)