Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

The next logical step in the evolution of interactivity on the Web was client-side executable content. This actually existed before Java in the form of helper apps and plug-ins. Through the use of helper apps—and helper apps that execute right in the browser, called plug-ins—it is possible to view and interact with Web content by using code that executes on your own machine. You simply need to download and install the helper software first (assuming it is available for your platform) and get the content later. The content is not executable but contains information about itself that tells the browser what program to use to interact with it. This is accomplished by use of a MIME (Multipurpose Internet Mail Extensions) type. This model allows a security risk on the client that is worse than the Java model because no limits are imposed on the application running on the client. The person using the helper application must trust that it won’t do any harm. The content (images, sounds, and movies) is not executable, and an end user must explicitly install the viewer software. Hence, no more risk exists than in installing any other kind of application.

What about the Java model? It is one big step forward for interactivity, which would typically cause security concerns. If the client can download executable code without knowing exactly what it does, what’s to prevent a malicious Java programmer from writing an applet that wipes out the user’s hard drive, infects files with viruses, steals private information, or crashes the machine? The remainder of this section describes these risks in more detail and talks about how these security risks have been closed in Java.

The Security Problem

How is network-distributed dynamic executable content any different from software installed and running on a local machine? A piece of software needs to be able to access all of the system resources within the limits of what the operating system allows. It typically needs to save files, read information, and access the system’s memory. Although defects exist in software as well as malicious attacks, the person installing the software generally makes a decision to trust the person who wrote the software. This approach is the traditional software model.

An application arriving over a network must also be able to make use of system resources in order to function. The only difference is that executable content arriving in a Web page does not need to be installed first. The user might not even know where it is coming from. If the applet needs access to key system resources, it will contact the browser and ask for special access. Typically, the browser responds by displaying a special dialog box, asking the user if he or she is willing to trust this applet. If the code was written by a malicious programmer who wanted to damage the end user’s machine or violate that user’s security, and if the end user was willing to grant that live content all the same freedoms a regular local application would have, the user would have no warning and no protection.

How do we allow for a useful applet and maintain a level of trust? It doesn’t make sense to completely restrict outside programs from doing anything on the local machine. Such an approach severely limits the functionality of the network application. A better strategy is to develop limitations that hinder the malicious behavior but allow for the freedom to do the things that need to be done. Six steps define this strategy:

1.  Determine in advance all potential malicious behavior and attack scenarios.

2.  Reduce all potential attack scenarios to a basic set of behaviors.

3.  Design a programming language and architecture that does not allow the basic set of behaviors that forms the basis for attack. Hopefully, this disallows the malicious behavior.

4.  Prove that the language and architecture are secure against the intended attack scenarios.

5.  Allow executable content using only this secure architecture.

6.  Design the language and architecture to be extensible so that new attack scenarios can be dealt with as they are discovered and new countermeasures can be retrofitted into the existing security measures.

Java was designed with each of these steps in mind, and it addresses most, if not all, of these points. Before exploring Java’s security architecture, we’ll discuss the types of potential attack scenarios.

Potential Attack Scenarios

An adversary may try to perpetrate two basic categories of attack. The first of these is the security breach; the second is the nuisance attack. Some examples of nuisance attacks are as follows:

•  Application starts a process that hogs all system resources and brings all computer use to a halt.

•  Application locks the browser by attacking it internally.

•  Application interferes with or reassigns the browser’s Domain Name Service (DNS) server. Such an attack can prevent the user from loading documents and possibly cause a security breach if the user were on as the privileged superuser (called root in UNIX and Administrator in Windows NT).

•  Application searches and destroys other applications by interfering with some specific process. Someone has written a Java applet, for example, that kills any other Java applets that try to load.

•  Application displays obscene pictures or profanity.

•  Application deletes or damages files on your computer.

These types of attacks might not necessarily open you up to a security breach because they do not leak private information about your company or yourself to any unauthorized third party. They can, however, make your computing experience unpleasant and even damage your computer’s operating system. The goal of these attacks is to wreak havoc of one type or another.

The other, more serious, types of attacks are security breaches, where somebody attempts to gain private or sensitive information about you or your business. More strategies are used to accomplish this than can be covered in a single chapter of a book. You’ll find full coverage of the subject in Internet Security Professional Reference, Second Edition (New Riders, 1997) and Maximum Security, Second Edition (Sams, 1998). A few of the major strategies that people might try include

•  Installing a back door into your network for future unauthorized access

•  Accessing confidential files on the network and giving them to an unauthorized third party

•  Usurping your identity and impersonating you or your computer to carry out attacks on other computers