Preface
The computer security issues surrounding Sun Microsystems, Inc’s Java language are of great enough concern to us that we decided to write a book. Although this book gets somewhat technical in places, we have attempted to make the issues clear enough so that current Java users (including people whose only brush with Java is running the occasional applet while surfing the web) can make sense of the often obscure and mysterious security concerns that Java raises. We do not intend to answer the question as to whether or not you should use Java, nor do we intend to scare anyone away from Java. Instead, our goal is to inform you about the very real risks so that an intelligent policy regarding Java use can be reached.
It is important to emphasize that to be a Java user you do not have to be a Java programmer. In fact, many people are Java users without necessarily knowing it. Anyone who uses a Java-enabled browser like the Netscape Navigator or the Microsoft Internet Explorer to surf the web is at times a Java user. We estimate that around 90% of web users can in this way be classified as Java users. If you are a Java user, the information in this book is entirely relevant. You need to know what the risks are.
The field of computers moves very quickly. One of the tricky aspects of writing a topical book relating to the web (such as this one) is figuring out when to “stop” the action. This process can be likened to taking a picture of a movie. In that sense, this book is a snapshot of Java security. We hope we have succeeded in making this book a useful way to learn about Java security. In addition to material about the current model and its problems, we have included much material about probable future developments.
Chapter 1 provides a quick and cursory introduction to Java. Pointers are provided to more thorough Java texts that cover the in’s and out’s of the entire Java language in more detail. This is, after all, not a book on Java per se, but is instead a book on Java security. The purpose of Chapter 1 is to provide some context for the later discussion of Java’s critical security implications. Near the end of Chapter 1 we introduce the central idea of the book: weighing the benefits of Java use against the risks.
Chapter 2 introduces the existing Java security model in some detail. As a prelude to our discussion, we introduce common security terminology (such as denial of service attack) so that you can better understand some of the jargon associated with computer security, what that jargon actually means in the real world, and how particular attacks can be delivered through Java applets. The three-prongs of Java security defense are explained. These include the Byte-code Verifier, the Applet Class Loader, and the Java Security Manager. We also introduce the idea that Java security fundamentally relies on ensuring type safety. Java seems to have at least a rudimentary security policy, and it is apparent that the designers of Java gave security some thought. Chapter 2 answers the questions: What is Java’s existing security policy? and, How well are the ideas implemented in the current version of Java?
Chapter 3 delves more deeply into the existing Java security model by focusing attention on some of the well-publicized problems that have been discovered. This is where our discussion of hostile applets begins. We introduce some terminology that divides hostile applets into two camps — very dangerous attack applets that involve security breaches and merely annoying malicious applets that are more of a nuisance than anything else. The purpose of Chapter 3 is to discuss attack applets and to elucidate just how secure Java really is at the moment. Java users must be educated about current problems in Java security if they are to make informed decisions regarding Java use. Some problems in the first release (post alpha and beta) of the Java Development Kit have been addressed through patching; others have not. We will discuss both sets of problems in some detail.
Fundamentally less dangerous but still annoying, malicious applets are the topic of Chapter 4. We provide some general examples of malicious applets and describe what exactly they do. Unfortunately there are many unscrupulous individuals on the net who are more than happy to include Java in their list of offensive weapons. Our mission is to make Java users aware of common classes of attacks.
Chapter 5 has two overall goals, both of which are meant to positively impact the Java security situation. The first goal is to suggest some high level antidotes for Java security concerns that are not tied to particular attacks. Experts in computer security have pointed out several global deficiencies in the Java approach to security. Fixing some of these things would certainly improve the model. High level concerns addressed in part one of Chapter 5 include: programming language issues, formal analysis of Java, applet logging, trusted computing bases, and decompilation. Hopefully some of the high-level concerns we raise in Chapter 5 will be fixed in the near future. In the mean time, there are some guidelines for safer Java use that can be applied today. These guidelines make up the second part of Chapter 5. If you only have time to read one section of this book, the guidelines section should be the one.
Finally, we conclude with some hints about what may happen to the Java security model in the future. The JavaSoft division of Sun Microsystems is working hard to improve the existing security situation (which currently has, as we discuss throughout this book, some rather serious flaws). The browser companies, Netscape and Microsoft, are also working to improve Java security since many of Java’s security policies get defined by the browser. Cool things that should improve Java security will likely include: digitally signed applets, an in-depth analysis of the Java security model, and better Class Loaders and Security Managers.
We hope that this book is both informative and useful. Making intelligent decisions regarding the use of Java (especially in business and other mission-critical systems) requires some knowledge of the current risks. Our goal is to present this important material as clearly and objectively as possible. Armed with the knowledge that we present in this book, Java users and site managers can make better Java use policies.
