Java, Java, Java: Object-Oriented Problem Solving, 2024E

One of the most attractive features of Java is that extensive effort has been made to make it a secure language. This is especially important for a language that makes it so easy to implement networking applications. After all, nobody wants to download a Java applet that proceeds to erase the hard disk. Such an applet might be written by a cyber terrorist, deliberately aiming to cause severe damage, or it might be written by a cyber doofus, who inadvertently writes code that does severe damage.

What are some of Java’s techniques for guarding against either deliberate or inadvertent insecure code? One level of security is Java’s bytecode verification process, which the Java Virtual Machine performs on any “untrusted” code that it receives. Java checks every class that it loads into memory to make sure it doesn’t contain illegal or insecure code. Another line of defense is the so-called sandbox security model, which refers to the practice of restricting the kinds of things that certain programs can do. For example, the “sandbox” environment for Java applets restricts them from having any access whatsoever to the local file system.

Another restriction imposed on applets is to limit their networking capabilities. For example, a Java applet cannot create a network connection to any computer except the one from which its code was downloaded. Also, a Java applet cannot listen for, or accept, connections on privileged ports—those numbered 1024 or lower. Together, these two restrictions severely limit the kinds of client/server programs that can be built as applets.

Java sets aside certain locations as repositories for trusted code. For example, the Java class libraries would be placed in such a location, as would the directories where your Java programs are stored. Any class loaded from some other directory is considered untrusted. By this definition, applets downloaded over the Internet would be considered untrusted code.

Security enhancements introduced in JDK 1.2 are based on the concepts of “permission” and “policy.” Code is assigned “permissions” based on the security policy currently in effect. Each permission specifies the type of access allowed for a particular resource (such as “read” and “write” access to a specified file or directory, or “connect” access to a given host and port). The policy that controls permissions can be initialized from an external configurable policy file. Unless a permission is explicitly granted to code, it cannot access the resource that is guarded by that permission. These new enhancements offer a more fine-grained and extensible approach to security for both applets and applications.

As this brief overview illustrates, the Java Virtual Machine is designed with security as one of its primary issues. This doesn’t guarantee 100 percent security, but it is a big improvement over some of the languages and systems that preceded Java. Moreover, security is an ongoing concern of the Java development process. Flaws in the existing security system are fixed very quickly. Advanced methods are constantly being developed and incorporated into the system. One such enhancement is the use of encryption to guarantee the integrity of classes transferred over the network.