7.3. Applet Security
One of the most important features of Java is its security model. It allows untrusted code, such as applets downloaded from arbitrary web sites, to be run in a restricted environment that prevents that code from doing anything malicious, like deleting files or sending fake email. The Java security model has evolved considerably between Java 1.0 and Java 1.2 and is covered in detail in Java in a Nutshell.
To write applets, you don't need to understand the entire Java security model. What you do need to know is that when your applet is run as untrusted code, it is subject to quite a few security restrictions that limit the kinds of things it can do. This section describes those security restrictions and also describes how you can attach a digital signature to applets, so that users can treat them as trusted code and run them in a less restrictive environment.
The following list details the security restrictions that are typically imposed on untrusted applet code. Different web browsers and applet viewers may impose slightly different security restrictions and may allow the end user to customize or selectively relax the restrictions. In general, however, you should assume that your untrusted applet are restricted in the following ways:
7.3.1. Local Applets
When an applet is loaded from the local filesystem, instead of through a network protocol, web browsers and applet viewers may relax some, or even many, of the preceding restrictions. The reason for this is that local applets are assumed to be more trustworthy than anonymous applets from the network.
Intermediate applet security policies are also possible. For example, an applet viewer can be written so that it places fewer restrictions on applets loaded from an internal corporate network than on those loaded from the Internet.
7.3.2. Signed Applets
Java 1.1 added the ability to attach a digital signature to a JAR file that contains an applet. This signature securely identifies the author or origin of an applet. If you trust the author or originating organization, you can configure your web browser or applet viewer to run applets bearing that signature as trusted code, rather than as untrusted code. Such an applet runs without the onerous security restrictions placed on untrusted applets. Java 1.2 platform actually allows the security policy to be customized based on the origin of an applet. This means that an end user or system administrator may define multiple levels of trust, allowing fully trusted applets to run with all the privileges of a standalone application, while partially trusted applets run with a reduced list of security restrictions.
The process of attaching a digital signature to an applet's JAR file is platform dependent. In Java 1.1, you use the javakey program. In Java 1.2, this program has been superseded by jarsigner. Netscape and Microsoft also provide their own digital signature programs that are customized for use with their browsers.
The process of telling your web browser or applet viewer which digital signatures to trust is also vendor dependent, of course. In Java 1.1, you use javakey to specify which signatures are trusted. In Java 1.2, you use a different tool, policytool, to specify trusted signatures and the security policies associated with them. See Java in a Nutshell for further details.
Copyright © 2001 O'Reilly & Associates. All rights reserved.