In the beginning, the Web (WWW) was a collection of static
HTML pages. To make the Web more interactive, graphical, and intelligent, a
number of technologies have been developed, which can be embedded in HTML pages.
These include HTTP cookies, Java applets, JavaScript, ActiveX components and
more of their type. We interact with all these when using a Web browser. Though
they do add welcome features to the sites, on the flip side, they also pose some
threats to users. In this article we’ll see how safe these are safe. We’ll
also see how to configure Internet Explorer and Netscape Navigator for safe
browsing.
Let’s begin by first understanding how the technologies
work.
Cookies
By definition cookies are nothing but text files, which are
used to keep track of a user’s preferences on a Website. They can be used to
present a customized interface to the user on his subsequent visits. A simple
example would be a site that lets you change its background color. When you make
a choice, say a blue background, a cookie is sent by the Web server to your
browser. The cookie contains in plain text, the name of the item which is ‘background’,
its value which is ‘blue’, an expiration time after which the cookie is not
accessible by the site, and a value (0 or 1) indicating whether the cookie is
sent through a secure connection using SSL (Secure Socket Layer).
Per session cookies are those, which exist only for one user
session. We can look at the contents of a cookie in a text editor like Notepad.
They can be found in C:\Windows\Temporary Internet Files in case of Internet
Explorer. In the case of Netscape the cookie’s information is appended to the
file cookies.txt found in C:\Program File\Netscape\Users\ default. Being just
normal text files, cookies can’t install viruses or trojans. Nor can they
steal your personal information. Moreover, a server can only read those cookies,
which are sent by it.
However, cookies can potentially be used to track your
preferences and build a profile, which can then be used to target appropriate
marketing messages at you.
Java applets
One of the reasons why Java became popular initially was due
to its capability of adding graphics and animation to Websites. Java programs
used in Websites, which can only be run in a Web browser are called Java
applets. Applets are powerful as they are developed using a full-fledged
programming language–Java– which can also be used to develop full-blown
applications. The applets share and use the same library API (Application
Programming Interface) or functions as normal applications. In other words,
applets can do all that an application can. So does that mean that an applet
downloaded from a site can read and write any file on your hard disk?
The answer is no, it can’t. To understand why, we must go
though the procedure of compilation and execution of a Java program (an applet
or an application).
Java is platform independent and it runs over a virtual
machine called Java Virtual Machine or JVM. When a Java program is compiled, it
produces what’s called class bytes, which are in a file with a .class
extension. These class bytes are instructions to the JVM. When these class bytes
are executed, they must be first loaded into the JVM by a class loader program.
But before the loading, a verifier program checks the integrity of these
instructions. Then a security manager program parses these instructions. Finally
the instructions are loaded into the JVM and then executed.
In case of applications there is no security manager. But in
case of applets, an applet security manager comes into play. The applet security
manager doesn’t allow the applets to read or write any file on your hard disk.
The applets can’t make a network connection to any of the services running on
your machine like a database. They can connect back only to the server from
where they were downloaded. Applets can’t access system information like user
accounts, current directory and system environment variables. Browsers have
built-in JVM and applet security managers. The applets run under the constraints
of the browser’s security manager, also called Sandbox.
The restrictions of the security manager hinder the
deployment of applets, which need some privileges or an intranet-like
environment. The solution to this is a signed applet. Such applets embed a
digital certificate (See article, What Digital Certificates Do, page 84, in this
issue) revealing the author or the developer of the applet. The digital
certificate is verified to be from a trusted CA and subsequently the applet is
allowed to run with more privileges.
Client-side JavaScript
JavaScript is a scripting language that runs within a
browser, completely on the client side. Some of its common uses are in checking
whether an HTML form has been filled correctly, displaying a simple animation,
etc. It’s also used in Dynamic HTML. It’s not a full-fledged programming
language and thus has limited capabilities. Its access is confined to the
browser and the HTML document within which it resides. But a script in one
document can access another document (say in the adjacent HTML frame) provided
both the documents reside on the same server. JavaScript has no capability to
read or write files on the hard disk. It can be used to send and read a cookie
file. Also a JavaScript can communicate with a Java applet. Sun and Netscape
have come up with the concept of signed scripts similar to signed applets. As
you may have guessed, signed scripts have greater access privileges and can even
access local files (though under the hood the script calls the Java File I/O
methods). Microsoft’s answer to JavaScript is Jscript, which adds some more
features and works only in Internet Explorer.
Microsoft ActiveX
ActiveX are software components, which are similar to Java
applets in the Web environment. They are written using full-fledged programming
languages like Microsoft Visual C++ and Visual Basic. Besides enhancing the
browsing experience, ActiveX technology can be used to develop plug-ins to
extend the capability of the browser. Only Internet Explorer supports ActiveX.
Netscape doesn’t have native support, but some third-party plug-ins are
available to run ActiveX in Netscape.
Unlike Java, ActiveX components don’t run under a security
model. They either run with full privileges or can’t be run at all. The only
authentication used for ActiveX components are again digital certificates.
Are you really safe?
As you might have noticed, a secure design goal has been
followed by almost all these technologies. But unfortunately, that has been only
in theory. In practice, there have been numerous bugs, which makes us suspicious
about our privacy and safety on the Web.
For example, cookies may sometimes contain confidential
information like your password to log on to a site. Since they are plain text
files (unless transferred using SSL), the information in them can be sniffed or
read when you are away from your desk. Due to vulnerabilities in browsers, a
server can read cookies, which didn’t originate from it.
Similarly, due to bugs in the virtual machine implementation
in browsers, there has been news of Java applets being able to surpass or trick
the security managers and read/write the files on the client’s hard disk.
JavaScript, though a simple scripting language, has also been
found to be unsafe. Due to some bugs, JavaScript can read the files on the local
hard disk, read URLs in the browser’s cache, and send e-mails without user’s
knowledge, etc. Also its ability to interact with Java applets can be used to
malicious ends. Unsigned ActiveX components can play havoc on the user’s
machine.
Newer bugs are being discovered and patches being offered
continuously. Users can only try to and keep their setups updated.
Safe browsing
Given all these documented and undocumented vulnerabilities,
what do we do? Stay off the Web? The better answer lies in the fact that both
Internet Explorer and Netscape Navigator have options for disabling or
controlling what these Web technologies can do. Disabling them altogether is not
a good option, as we will be missing out on a wealth of features that the
dynamic Web offers. The trick lies in choosing how much of your door you want to
keep open.
In Internet Explorer you can set your security settings from
Tools>Internet Options>Security. Now click on the ‘Custom Level’
button. Depending on your version of Explorer, you get a host of security areas
and different setting options under each. For example, under the cookie section,
you can select from among the three options: Enable, Disable or Prompt.
Selecting Prompt will ask you before downloading a cookie. In Netscape
Navigator, going to Edit> Preferences>Advanced gives you such options.
Netscape Navigator’s applet security manager is quite
strict and simply disallows everything against its applet security manager. You
can enable or disable Java applets from Edit> Preferences>Advanced. In
Internet Explorer, you can select what an applet can do. Go to Tools>Internet
Options> Security and click on Custom Level. Go to the Java section and
select Custom. A button labeled Java Custom Settings will appear. Now, from the
Edit Permissions tab you can select what an applet can do. Here you can see a
section named Permissions that signed contents are allowed. In Internet
Explorer, you can configure what a signed applet is allowed to access.
In Internet Explorer, again from the Custom settings, under
the Scripting section you can control the scripts, which include JavaScript,
Jscript, and VBScript. You can disable scripts altogether and restrict the
scripts to interact with Java applets. In Netscape you have the option of either
enabling or disabling JavaScript from Edit>Preferences> Advanced.
In Internet Explorer, you can select whether to run unsigned
ActiveX controls or not from the ActiveX section. Also, like Java applets, a
script can interact with an ActiveX component. Under this section you can also
decide to allow this or not.
In Netscape Navigator, you can either enable or disable
cookies, JavaScript, Java applets from the Edit>Preferences> Advanced.
Shekhar Govindarajan