Java Applet Security Model

Java Applet Security Model

The standard Java applet security model forces downloaded Java applets to run within a highly restrictive sandbox, severely limiting their capabilities as well as the damage they can do to the user's system. The sandbox prevents applets from accessing the machine's file system, which includes the registry on a Windows box, and does not allow them to launch other programs. Additionally, applets cannot communicate with any system on the network except with the host from which the browser downloaded them. I've always been surprised by the use of the word sandbox to describe this critical component of the Java security model. Although this word invokes happy images of children playing peacefully, most parents know that children playing in a sandbox can jump out of the sandbox and spread sand everywhere. Who uses a sandbox to improve security? I use locks, keys, cages, and other physical devices to protect my stuff. Therefore, I think of the Java sandbox as more of a locked cage. Java applets can operate within the cage, but cannot reach outside of the cage to cause any damage (provided that the cage itself is secure, of course).

In the example depicted in Figure 4.12, the SSH applet was operating within these sandbox restrictions. Therefore, I was only able to make an SSH connection to the Web server that was hosting the applet. If I asked the applet to connect to another host, say ftp.example.com, for example, the JRE would block the attempt and present me with the following error message:

Code View: Scroll / Show All

java.security.AccessControlException: access denied (java.net.SocketPermission ftp.example.com resolve)