Check out the new USENIX Web site. next up previous
Next: Signed Applets Up: WWW Electronic Commerce and Previous: Paper outline

Java

 

Java is a programming language and associated set of development tools developed by Sun Microsystems. Similar to C++ in syntax, Java is intended for writing programs that will be runnable on a variety of dissimilar computer architectures. This is accomplished by compiling Java programs into an machine-independent byte code format, which can then be run on any computer equipped with a Java interpreter.

Java can be used to write stand-alone applications, but it has gained its widespread popularity by its use to create applets, which are executable objects written in Java and embedded in World Wide Web pages. When a web page containing a Java applet is loaded into a Java-enabled browser, the applet's byte code is also loaded, interpreted and executed within the browser. Applets can be used to create web pages containing animation loops, arcade games, and other highly interactive applications which would have been infeasible if executed from the server due to latency and server load.

Executing applets in a secure manner must necessarily be the responsibility of the client's web browser. Java-enabled web browsers are expected to make use of Java's well defined type system in order to verify that the byte code they receive corresponds to a valid Java program. The Java language also includes an extensive application program interface (API) specification, which is the only way that applets can perform any input/output or other system functions. The web browser must include an implementation of the Java API class libraries, with appropriate restrictions on what applets, as untrusted code, are allowed to do.

In this discussion, we will consider Netscape Navigator as our example of such a Java-enabled web browser. Navigator incorporates three significant security restrictions in its version of the Java API:

  1. No access to the local filesystem is allowed.
  2. Socket connections are allowed only to the server on which the web page containing the applet resides.
  3. Windows and dialogue boxes opened by applets contain vivid banners labeling them as ``Untrusted Java Applet Window''.

Recent work by Dean, Felten and Wallach [5] has focused on security flaws in Netscape Navigator Java which are due to implementation errors, such as significant weakness in the Java class loader. These flaws may be exploited by a sophisticated attacker in order to bypass any or all of the above API security restrictions. In our work, by contrast, we have chosen to assume a correct implementation of Java in which the intended security restrictions are perfectly enforced, and to show that there exists a particular type of attack on security which is not prevented or even significantly hindered by these restrictions.

We begin by pointing out that Java applets are allowed complete control over the screen pixels that fall within their allotted area of the browser window, and that it is unrealistic to expect that any significant limits could be placed on this control while still allowing applets to perform animation. Similarly, applets have full access to information about mouse and keyboard events that occur within that area, and that access cannot be limited much without severely hampering the interactivity that applets are intended to provide. The combination of these two abilities allows applets to bypass the third security restriction with relative ease, since it is a simple matter for an applet to draw and manage its own dialogue box within the confines of the browser window. Not only would such a dialogue box have no warning banner, it could have any appearance that the applet's designers desire.

If a rogue applet is successful in stealing information from its host environment, whether by tricking it out of the consumer or through some other method, the second security restriction does little to prevent the applet from transmitting its stolen information over the network. The applet may, with perfect legitimacy, connect back to its server via socket and report what it has stolen; alternatively it may simply make an http request to any machine on the network and include its stolen information as part of the request string.

In summary, even given a hypothetical perfect implementation of Java and the listed Navigator security restrictions, a rogue applet is still free to trick information out of the consumer through clever control of its area of the screen display, and can easily communicate such stolen information over the network to any accomplice it desires.




next up previous
Next: Signed Applets Up: WWW Electronic Commerce and Previous: Paper outline

TOM Comversion
Fri Oct 4 17:27:59 EDT 1996