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, Builder.com | 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
concerns.
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.
http://www.zdnet.com.au/builder/program/web/story/0,2000034810,20274092,00.htm
Responses
Post a New Response
The TeamJava Forum is maintained with WebBBS 2.24.