Applets loaded over the network are usually considered to be untrusted code. (The exception, as we'll see in the next section, is when the applet bears the digital signature of an entity that you've specified you trust.) The only way to be sure that an untrusted applet cannot perform any malicious actions (e.g., deleting your files, sending out fake email that looks like it came from you, using your computer as a remote file server) is to run it in a tightly controlled environment. For this reason, Web browsers and applet viewers carefully restrict what an applet is allowed to do. When designing an applet, you must be aware of a fairly long list of things that an applet is not allowed to do. The following list details the security restrictions imposed by the appletviewer application in Java 1.1. Different Web browsers and applet viewers may impose somewhat different restrictions on applets, and some (including appletviewer) may allow the user to relax or customize the restrictions. In general, however, you should assume that your applets will be restricted in the following ways:
When an applet is loaded from the local file system, instead of through a network protocol, Web browsers and applet viewers may relax some, or even many, of the above 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 could be written that would place fewer restrictions on applets loaded from an internal corporate network than on those loaded from the Internet.
Implementing the security restrictions described above is the responsibility of the java.lang.SecurityManager class. This class defines a number of methods that the system calls to check whether a certain operation (such as reading a file) is permitted in the current environment. Applet viewers create a subclass of SecurityManager to implement a particular security policy. A security policy is put in place by instantiating a SecurityManager object and registering it with System.setSecurityManager(). (One of the obvious security restrictions that must be enforced is that untrusted code may not register its own SecurityManager object!)
Another component of Java security is the way Java classes are loaded over the network. The java.lang.ClassLoader class defines how this is done. Applet viewers and Web browsers create subclasses of this class that implement security policies and define how class files are loaded via various protocols.
One important function of the class loader is to ensure that loaded classes reside in a separate namespace than classes loaded from the local system. This prevents naming conflicts, and also prevents a malicious applet from replacing standard Java classes with its own versions.
Another important function of the class loader is to ensure that all untrusted Java code (generally code loaded over the network) is passed through the Java byte-code verification process. This process ensures that the loaded code does not violate Java namespace restrictions or type conversion restrictions. It also checks that the code:
The purpose of these checks is to verify that the loaded code cannot forge pointers or do memory arithmetic, which could give it access to the underlying machine. The checks also ensure that the code cannot crash the Java interpreter or leave it in an undefined state, which might allow malicious code to take advantage of security flaws that could exist in some interpreter implementations. Essentially, the byte-code verification process protects against code from an "untrusted" Java compiler.
The one "security hole" that remains when running an untrusted applet is that the applet can perform a "denial of service attack" on your computer. For example, it could frivolously allocate lots of memory, run many threads, or download lots of data. This sort of attack consumes system resources and can slow your computer (or your network connection) considerably. While this sort of attack by an applet is inconvenient, fortunately it cannot usually do any significant damage.