Java Security, 2nd Edition

Comparisons with Previous Releases

At the level of the Java language, little has changed between Java 1.1 and any release of the Java 2 platform. One thing which has changed is bytecode verification: in 1.1, the virtual machine did not perform bytecode verification of classes on the classpath. This is really a reflection of class loading policies: starting with the Java 2 platform, classes on the classpath are loaded by a traditional class loader, which subjects them to verification.

Controlling Bytecode Verification

Bytecode verification seems like a great thing: not only can it help to prevent malicious attacks from violating rules of the Java language, it can also help detect simple programmer errors -- such as when we changed the access modifier of acctNo in our CreditCard class but forgot to recompile our Test class.

Nonetheless, in 1.1 only classes loaded by a browser are subject to bytecode verification. In typical usage, this is a workable policy. Browsers always ensure that the code imported to run an applet is verified, and Java applications are typically not verified. Of course, this may or may not be the perfect solution:

• If a remote site can talk an end user into installing a local class in the browser’s classpath , the local class will not be verified and may violate the rules we’ve discussed here. In Java 2, this is much harder since the class must be added to the jar file containing the core API classes.

• You may implicitly rely upon the verifier to help you keep ...