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

In addition to strong typing and overflow protection, Sun’s engineers also took advantage of the object-oriented nature of the language itself to add security. With the exception of the primitive types, everything in Java is a basic object. This strict adherence to object-oriented methodology means that all the theoretical benefits of object-oriented programming (OOP) are realized in Java. These include

•  Encapsulation of data within objects

•  The capability to inherit from existing secure objects

•  Controlled access to data structures via public methods only, so no operator overloading occurs

Every Java object has a unique hash code associated with it. This feature enables the current state of a Java program to be fully inventoried at any time, enabling the Java Virtual Machine to watch for unauthorized objects.

How Java Provides Security over the Internet

Because of the protection of the JVM and the language itself, most users can run most applets and be confident that the applet will “play in its own sandbox” without interfering with system resources on the end user’s machine. Sometimes, however, you need to write an applet that accesses those system resources, and the end user is willing to trust that you won’t damage his or her system or steal confidential information.

The problem is that an end user downloading your applets over the Internet could be duped into running malicious applets written by someone else. Figure 41.3 illustrates the problem, known as the “man-in-the-middle” attack.

FIGURE 41.3  Bob thinks he’s trusting the applet written by Alice, but in reality, he’s running an applet written by Charlie.

In this example, Bob has connected to Alice’s server. His browser downloaded a Web page that included an applet. In reality, Charlie has programmed his server to intercept the applet on its way to Bob and substitute Charlie’s version of the applet. While Bob thinks he’s trusting Alice’s applet, in reality he has opened his system to a malicious applet written by Charlie.

	ON THE WEB
	http://www.cs.princeton.edu/sip/pub/spoofing.html For a technical description of how a man-in-the-middle attack applies to the Web, read this paper on web spoofing developed by the Secure Internet Programming team at Princeton University.

The solution to this problem is offered by an applet-level security mechanism called the JavaSecurity API. (An API is an Application Programming Interface—a way for a library developer to give the programmer access to a set of features.)

One of the capabilities offered in the JavaSecurity API is digital signing. To use this capability, bundle your Java class files and any related files that your applet needs into a Java archive (JAR). You then electronically sign the JAR file. When the end user retrieves the JAR from your server, he or she can verify your signature. If a man in the middle attempts to substitute a different applet, the signature will not verify and the end user is warned about the forgery.

	ON THE WEB
	http://java.sun.com/products/jdk/1.1/docs/guide/jar/jarGuide.html Learn more about the Java archive format. Here you’ll learn how to reference a JAR in the <APPLET> tag instead of a class file.

Applets Versus ActiveX Controls

The only serious competitor to Java applets is offered by Microsoft and is called ActiveX controls. ActiveX controls are an Internet version of an older standard, called OCX controls. These controls can be written in any language and can do anything that anyone can do in that language. No technical reason prevents an ActiveX programmer from writing a trojan horse that deletes every file on your hard drive or that copies confidential information back to the Internet. Microsoft has tried to address this problem by encouraging ActiveX developers to use their code-signing facility, making ActiveX controls proof against man-in-the-middle attacks.

Sun’s approach, with Java, is different, with security checks built into the language itself. As you’ll see, Sun also supports signed applets, which the end user may choose to trust.

The Microsoft Way

Microsoft’s approach means that every ActiveX control functions like a trusted Java applet. Because most end users will not want to download unsigned ActiveX controls, no equivalent exists to the untrusted applet, in which security is ensured by the Java sandbox.

If an end user chooses to trust all ActiveX controls, sooner or later the end user’s machine may fall victim to an attack. With most attacks, it may be difficult to determine which ActiveX control was responsible. An ActiveX control could replace a system file such as move.exe, for example, and then alter itself so the malicious part of the ActiveX control was deleted. The next time the end user attempts to move a file, the trojan horse version of move.exe runs, accomplishing the malicious programmer’s objective. Even if the end user detects the problem, it will be difficult to trace the problem back to the specific ActiveX control.

---

NOTE:  Microsoft’s side of the applet vs. ActiveX argument is that Java represents a “lowest common denominator.” Microsoft casts the argument not as “Java vs. ActiveX” but as “PCs vs. Sun.” They also point to http://www.webfayre.com/pendragon/jpr/index.html, which benchmarks Java performance on a number of different machines. (Windows NT and Windows 95 running on high-speed Pentiums outperform all other platforms.)

---

Java Browser Restrictions

Sun recommends that browser vendors limit applets by enforcing three rules. These rules are enforced by the Sun code licensed by major browser vendors, such as Netscape Communications and Microsoft, as well as by the Sun Java plug-in:

•  Untrusted applets cannot access the local hard drive.

•  All standalone windows put up by untrusted applets are labeled as such. Figure 41.4 shows such a window.

•  Untrusted applets can establish a network connection only back to the server from which they were loaded.

FIGURE 41.4  The browser warns the user if a window was opened by an untrusted applet.

The first rule closes most security holes. If an applet cannot read the local hard drive, it cannot access most confidential information. If it cannot write the hard drive, it cannot plant viruses or trojan horses.

The second rule makes it less likely that the user will inadvertently enter confidential information (such as a credit card number) into an untrusted applet.