Heave an egg through an open window almost anywhere in the world today, and the odds of striking a Netscape user are in your favor. The odds are even better that this person either knows nothing of Java programming or adheres to the many myths surrounding Java security. Pick up almost any book on Java programming, and you will find the same superficial and misleading treatment of security issues. Gary McGraw and Edward Felten's recent work, "Java Security: Hostile Applets, Holes, and Antidotes," is the first book to address the myriad problems raised by Java. It clearly and concisely explains past problems, current issues, and future risks. McGraw and Felten grab the high and mighty Java industry by the ear, and they offer sane and sensible advice to every level of Java programmer and user.
One of the strongest points of the book is that it offers as much to the Java neophyte as it does to the seasoned programmer. The first chapter provides a brief survey of Java's concepts, while the second chapter gives a detailed introduction to the current Java security model. From the beginning the reader is led to pose tough questions and weigh the risks versus the benefits of using Java. The book's classification of threats from applets is apt, as is its classification of hostile applets into two camps - the more serious "attack" applets, such as those created by Felten's team at Princeton, and the less threatening "malicious" ones, such as those on display on the Hostile Applets Home Page. Two chapters provide the essence of both types of applets, and the penultimate chapter proposes six common sense guidelines for using Java more safely. It would be a grave mistake for anyone to ignore the book's questions or to accept the answers on faith from some corporate behemoth.
Unlike many books aimed primarily at the novice, "Java Security" has much to offer the experienced Java programmer. Foremost of all, its critical attitude toward Java security is a breath of fresh air for the legions of self-styled "Java Consultants," who all too often have inhaled the wind of a flatulent Duke for far too long. Those already acquainted with Java will find the detailed discussions of "attack" applets in Chapter 3 and "malicious" applets in Chapter 4 very profitable. The book's final chapter on "Tomorrow's Java Security" is a nice preview of new security features likely to appear in future releases of Sun's Java Developers Kit. While these portions of the book are more suitable for the seasoned Java user, the novice willing to look elsewhere for some additional details will certainly profit.
Without a doubt the most exciting and enlightening chapter of the book is the fifth one, "Antidotes and Guidelines for Java Users." It succeeds admirably in its twin goals of discussing high-level concerns about Java and providing a concise set of security guidelines for users to follow. Remarkably, although it is the shortest chapter in the book, in the course of its first dozen pages it offers as many sound reasons why Java will continue to pose security risks.
One of the most interesting observations to emerge in this chapter is that Java byte code is more powerful than Java source code. While every program written in Java can be compiled to byte code by a Java compiler, it is possible to create class files which no Java compiler can produce, and yet, which pass the Verifier with flying colors. Not only is it possible to create such non-compiler class files, it is a simple matter to do so, and the number of such non-compiler class files far and away exceeds the number of class files producible by Java compilers. Thus no matter what claims are made, and even demonstrated, for the security of the Java language, all bets are off when it comes to byte code running in the Java Virtual Machine. This is one of the most important facts brought to light in the book, and it is a topic crying out for more active research.
Another interesting item mentioned in Chapter 5 is that the ease with which Java class files may be decompiled to source code also entails certain risks. Using the celebrated Mocha decompiler, for example, it is easy for a hacker to decompile class files to source code and scour them for weaknesses, and it is just as easy for a Java developer to decompile a business competitor's work and search for trade secrets. It is worth observing that these two topics in Chapter 5 are not unrelated. There is now available a Java application, HoseMocha.java, that strategically adds byte code to Java class files. Class files protected by HoseMocha continue to pass the Verifier and run just as before, but they defeat the Mocha decompiler because there is no source code that can produce them. The Mocha decompiler could be taught to defend itself, of course, but it is unlikely to be able to do so effectively against the wealth of byte code tricks that can be used to attack it. The power of Java byte code is simply too much greater than the power of Java source code. This fact is likely to pose a continuing threat to the security of the Java language for years to come, and it may well prove fatal.
In fairness, it should be noted that the list of references in "Java Security" has several errors and significant omissions. It seems likely that the errors are due to editorial carelessness, and they cannot be said to detract much from the book's success. Missing from the references are the authoritative works in "The Java Series," written by members of the JavaSoft team and published by Addison-Wesley. Particularly worthy of inclusion are "The Java Language Specification" by Gosling, Joy, and Steele as well as "The Java Virtual Machine Specification" by Lindholm and Yellin. The authors definitely should consider including these in the references. Perhaps these minor foibles will be corrected in a later printing or a second edition.
The only other shortcoming that could be corrected is the book's length. It is altogether too short, and a work of twice the present length on the same subject would still leave much remaining to be said. But perhaps this is a strength of the book and not a weakness. One can only wish that McGraw and Felten's "Java Security" had appeared a year earlier and had already been read by Java's cheerleaders and hucksters. Perhaps then more of the problems discussed in this book would have been solved by now, and fewer risks would remain. Until those problems are addressed, and even after they are, "Java Security" will be a fine antidote for all of the Java fanfare.