Applet Security Survey
Introduction
Making a software online and public is the easiest way to spread a software around the world. Just upload it in a very popular FTP or WWW site, and announce it in widely-read news groups or discussion lists, your program might have a download rate of all times a public software can have. How powerful is this? It is this feature that attracts many productive and respective programmers as well as ill-minded ones.
Sun's solution to client/server programming over open and distributed networks was Java applets with many restrictions aimed on different security problems.
In general, applets loaded over the net are prevented from
Related Sites
When an applet is loaded from a local file system, instead of 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.
Applet Security Implementation
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().
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.
Another important function of the class loader is to ensure that all untrusted Java code is passed trough 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 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.