Content URL: Link To Content
Java has become much more complicated and multifaceted than it was when it was introduced. No longer simply a client-side language for applets, Java can now be found on everything from enterprise application servers to embedded devices like smart cards. We have tried to address security factors from throughout the entire Java range in this book.
We hope this book appeals to geeks and grandmothers alike (not that some grandmothers aren't geeks). Although it gets technical in places, we hope the messages are clear enough that even the casual Web user comes away with a broader understanding of the security issues surrounding mobile code. We kept four groups in mind as we wrote this book: Web users, developers, system administrators, and business decision-makers. Many of the issues of mobile code security cut across these groups. As Java integrates itself into the foundations of electronic commerce, Java security issues take on more urgency.
Java is only one kind of mobile code among many. Other systems immersed in the same security dilemma include ActiveX, JavaScript, and Word Macros. It is essential not to get the wrong message from this book. Our focus on Java is no accident. We believe Java is the most viable mobile code system created to date. Don't believe that through our work we imply that other systems are any more secure than Java. Just the opposite is true.
With the introduction of code signing to Java (in JDK 1.1) and its enhancement with access control (in Java 2), securing Java became much harder. Java's position along the security/functionality tradeoff has moved significantly toward functionality, to the detriment of security. This is good if you want more functionality, which most businesses and developers seem to need, but it is bad if you are charged with managing security risks. Forming an intelligent Java use policy is more important than ever, but doing so is more complicated than it used to be.
The computer field moves so fast that people have begun to refer to Internet time to grapple with its constantly accelerating speed. Three months is a year in Internet time. Java is directly involved in the speed of the field, and has done its share to make things move even more quickly. One tricky aspect of writing a topical book relating to the Web is figuring out when to stop the action. This process can be likened to freeze-framing a picture of a movie. In that sense, this book is a snapshot of Java security. We hope we have succeeded in making it a useful way to learn about Java security. For up-to-date information, see the book's companion Web site at www.rstcorp.com/java-security.html.
As we went to press, Sun Microsystems renamed JDK 1.2 and called it Java 2. We have attempted to use correct version numbers throughout and apologize for any confusion.
Chapter 1, "Mobile Code and Security: Why Java Security Is Important,"," sets the stage with a discussion of the four intended audiences. As Java matures, it is making important inroads into the enterprise world. That means Java security is now as important to business people and system administrators as it is to Web users and Java developers. For the uninitiated, Chapter 1 provides a quick and cursory introduction to Java. Pointers are provided to more through Java texts that cover the ins and outs 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. We also spend some time discussing why the once-important distinction between applets and applications has been superceded by concerns about trust. It turns out that under the Java 2 architecture, applets can be completely trusted and applications can be completely untrusted. In fact, every kind of Java code can be doled out different amounts of trust, depending on what the user's policy says. Finally, we cover some other popular forms of mobile code and discuss how their security stacks up against Java. The main purpose of this chapter is to provide some context for the later discussion of Java's critical security implications and to introduce the central idea of the book: weighing the benefits of Java use against the risks.
Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," examines the base Java security model in some detail. As a prelude to our discussion, we introduce four categories of attacks, ranging from the very serious to the merely annoying: system modification, invasion of privacy, denial of service, and antagonism. We then discuss Java's programming-languages approach to security and introduce the three parts of the original applet sandbox. These include the Verifier, the Class Loader Architecture, and the Security Manager. We also introduce the idea that Java security fundamentally relies on ensuring type safety. The base sandbox provides the foundation of Java's new trust-based security model. Starting with a restrictive sandbox for untrusted code, restrictions can be lifted little by little until code takes on complete trust and is awarded full run of the entire system.
Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," examines Java's new trust-based security model. With the addition of code signing in JDK 1.1, Java's security architecture underwent a large shift. Java 2 completed the transformation with the addition of access control. It is now possible to create complex security policy for mobile code written in Java and have the Java system itself enforce the policy. The change certainly affords more power to mobile code than ever before, but it also introduces a major new risk to Java: a human-centered policy management risk. Setting up and managing a mobile code policy will be a complex and error-prone undertaking requiring security experience. JDK 1.1 and Java 2 rest on the notion of trust, which leverages the technological power of code signing. Understanding the new model requires understanding the way code signing and trust interact, and discounting some of the common myths associated with it. Chapter 3 ends with a discussion of stack inspection and the Java 2 code-signing API. (Appendix C, "How to Sign Java Code," is a code-signing tutorial covering Microsoft, Netscape, and Sun's three different code signing schemes.)
Chapter 4, "Malicious Applets: Avoiding a Common Nuisance," begins to discuss what happens when the Java security model is abused by hostile applets. Hostile applets come in two forms: very dangerous attack applets that involve security breaches, and merely annoying malicious applets that are more of a nuisance than anything else. Chapter 4 is all about malicious applets. Malicious applets are quite easy to create, and they are equally easy to find on the Web. Unfortunately, there are just as many unscrupulous individuals on the Net as there are in the rest of the world. Bad guys 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, "Attack Applets: Exploiting Holes in the Security Model," delves more deeply into the Java security model by focusing attention on some of the well-publicized security holes that have been discovered. This is where our discussion of hostile applets turns more serious. Securing Java is a difficult job, especially when it comes to implementing complicated models. Attack applets have been created in the lab that exploit the holes we discuss. Some of the holes are simple implementation bugs, while others indicate more serious design flaws. The good news is that Sun and other licensees take Java security very seriously and they respond quickly to fix any holes once they are discovered. We think discussing these holes is important since it emphasizes the true nature of computer security.
Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil," has two overall goals, both of which are meant to impact the Java security situation positively. The first 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 would certainly improve the model. High-level concerns addressed in Chapter 6 include programming language issues, formal analysis of Java, applet logging, trust, decompilation, applet monitoring, and policy management. Hopefully, some of the high-level concerns we raise will eventually be addressed in the Java platform itself. In the meantime, a number of third-party vendors are eager to help. The second goal of Chapter 6 is to introduce the players briefly and to discuss what risks third-party vendors can and cannot address. The computer security field has its share of snake oil, and complex issues such as mobile code security tend to be easy to exploit. One of our goals is to bring some realism to the table and arm you with the right questions to ask.
If you only read one chapter of this book, read Chapter 7, "Java Security Guidelines: Developing and Using Java More Securely." This chapter presents two sets of guidelines: one for Java developers and one for Java users. Writing security-critical code is not easy, and developers need all the help they can get. We offer 12 rules for writing safer Java. Although the rules get a bit technical, it is worth spending some time to figure them out. By contrast, our guidelines for Java users are simple to understand and follow; in fact, most of them are simply common sense.
Chapter 8, "Java Card Security: How Smart Cards and Java Mix," is devoted to Java on smart cards. We decided to include this chapter since Java Cards are likely to show up in millions of consumer wallets in the next few years. Smart card security is really too big an issue to cover in a single chapter, so we focus primarily on the security impact of putting a Java Virtual Machine on a card. Chapter 8 covers six key questions, including: What is a smart card?, Why put Java on a smart card?, and How does the use of Java impact smart card security?
We conclude by covering some of the challenges to mobile code that remain to be conquered. Chapter 9, "The Future of Java Security: Challenges Facing Mobile Code," presents a concise set of six central lessons we have learned during our time in the Java security trenches. We go on to discuss several open research issues that you're likely to hear about again. Finally, we discuss the notion of security assurance, an important strategy in securing Java.
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 disclose those risks-and countermeasures to curtail them-as clearly and objectively as possible. Armed with the knowledge that we present in this book, Java users, site managers, and business decision-makers can make better Java use policies.
Java has become much more complicated and multifaceted than it was when it was introduced. No longer simply a client-side language for applets, Java can now be found on everything from enterprise application servers to embedded devices like smart cards. We have tried to address security factors from throughout the entire Java range in this book.
We hope this book appeals to geeks and grandmothers alike (not that some grandmothers aren't geeks). Although it gets technical in places, we hope the messages are clear enough that even the casual Web user comes away with a broader understanding of the security issues surrounding mobile code. We kept four groups in mind as we wrote this book: Web users, developers, system administrators, and business decision-makers. Many of the issues of mobile code security cut across these groups. As Java integrates itself into the foundations of electronic commerce, Java security issues take on more urgency.
Java is only one kind of mobile code among many. Other systems immersed in the same security dilemma include ActiveX, JavaScript, and Word Macros. It is essential not to get the wrong message from this book. Our focus on Java is no accident. We believe Java is the most viable mobile code system created to date. Don't believe that through our work we imply that other systems are any more secure than Java. Just the opposite is true.
With the introduction of code signing to Java (in JDK 1.1) and its enhancement with access control (in Java 2), securing Java became much harder. Java's position along the security/functionality tradeoff has moved significantly toward functionality, to the detriment of security. This is good if you want more functionality, which most businesses and developers seem to need, but it is bad if you are charged with managing security risks. Forming an intelligent Java use policy is more important than ever, but doing so is more complicated than it used to be.
The computer field moves so fast that people have begun to refer to Internet time to grapple with its constantly accelerating speed. Three months is a year in Internet time. Java is directly involved in the speed of the field, and has done its share to make things move even more quickly. One tricky aspect of writing a topical book relating to the Web is figuring out when to stop the action. This process can be likened to freeze-framing a picture of a movie. In that sense, this book is a snapshot of Java security. We hope we have succeeded in making it a useful way to learn about Java security. For up-to-date information, see the book's companion Web site at www.rstcorp.com/java-security.html.
As we went to press, Sun Microsystems renamed JDK 1.2 and called it Java 2. We have attempted to use correct version numbers throughout and apologize for any confusion.
Chapter 1, "Mobile Code and Security: Why Java Security Is Important,"," sets the stage with a discussion of the four intended audiences. As Java matures, it is making important inroads into the enterprise world. That means Java security is now as important to business people and system administrators as it is to Web users and Java developers. For the uninitiated, Chapter 1 provides a quick and cursory introduction to Java. Pointers are provided to more through Java texts that cover the ins and outs 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. We also spend some time discussing why the once-important distinction between applets and applications has been superceded by concerns about trust. It turns out that under the Java 2 architecture, applets can be completely trusted and applications can be completely untrusted. In fact, every kind of Java code can be doled out different amounts of trust, depending on what the user's policy says. Finally, we cover some other popular forms of mobile code and discuss how their security stacks up against Java. The main purpose of this chapter is to provide some context for the later discussion of Java's critical security implications and to introduce the central idea of the book: weighing the benefits of Java use against the risks.
Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," examines the base Java security model in some detail. As a prelude to our discussion, we introduce four categories of attacks, ranging from the very serious to the merely annoying: system modification, invasion of privacy, denial of service, and antagonism. We then discuss Java's programming-languages approach to security and introduce the three parts of the original applet sandbox. These include the Verifier, the Class Loader Architecture, and the Security Manager. We also introduce the idea that Java security fundamentally relies on ensuring type safety. The base sandbox provides the foundation of Java's new trust-based security model. Starting with a restrictive sandbox for untrusted code, restrictions can be lifted little by little until code takes on complete trust and is awarded full run of the entire system.
Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," examines Java's new trust-based security model. With the addition of code signing in JDK 1.1, Java's security architecture underwent a large shift. Java 2 completed the transformation with the addition of access control. It is now possible to create complex security policy for mobile code written in Java and have the Java system itself enforce the policy. The change certainly affords more power to mobile code than ever before, but it also introduces a major new risk to Java: a human-centered policy management risk. Setting up and managing a mobile code policy will be a complex and error-prone undertaking requiring security experience. JDK 1.1 and Java 2 rest on the notion of trust, which leverages the technological power of code signing. Understanding the new model requires understanding the way code signing and trust interact, and discounting some of the common myths associated with it. Chapter 3 ends with a discussion of stack inspection and the Java 2 code-signing API. (Appendix C, "How to Sign Java Code," is a code-signing tutorial covering Microsoft, Netscape, and Sun's three different code signing schemes.)
Chapter 4, "Malicious Applets: Avoiding a Common Nuisance," begins to discuss what happens when the Java security model is abused by hostile applets. Hostile applets come in two forms: very dangerous attack applets that involve security breaches, and merely annoying malicious applets that are more of a nuisance than anything else. Chapter 4 is all about malicious applets. Malicious applets are quite easy to create, and they are equally easy to find on the Web. Unfortunately, there are just as many unscrupulous individuals on the Net as there are in the rest of the world. Bad guys 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, "Attack Applets: Exploiting Holes in the Security Model," delves more deeply into the Java security model by focusing attention on some of the well-publicized security holes that have been discovered. This is where our discussion of hostile applets turns more serious. Securing Java is a difficult job, especially when it comes to implementing complicated models. Attack applets have been created in the lab that exploit the holes we discuss. Some of the holes are simple implementation bugs, while others indicate more serious design flaws. The good news is that Sun and other licensees take Java security very seriously and they respond quickly to fix any holes once they are discovered. We think discussing these holes is important since it emphasizes the true nature of computer security.
Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil," has two overall goals, both of which are meant to impact the Java security situation positively. The first 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 would certainly improve the model. High-level concerns addressed in Chapter 6 include programming language issues, formal analysis of Java, applet logging, trust, decompilation, applet monitoring, and policy management. Hopefully, some of the high-level concerns we raise will eventually be addressed in the Java platform itself. In the meantime, a number of third-party vendors are eager to help. The second goal of Chapter 6 is to introduce the players briefly and to discuss what risks third-party vendors can and cannot address. The computer security field has its share of snake oil, and complex issues such as mobile code security tend to be easy to exploit. One of our goals is to bring some realism to the table and arm you with the right questions to ask.
If you only read one chapter of this book, read Chapter 7, "Java Security Guidelines: Developing and Using Java More Securely." This chapter presents two sets of guidelines: one for Java developers and one for Java users. Writing security-critical code is not easy, and developers need all the help they can get. We offer 12 rules for writing safer Java. Although the rules get a bit technical, it is worth spending some time to figure them out. By contrast, our guidelines for Java users are simple to understand and follow; in fact, most of them are simply common sense.
Chapter 8, "Java Card Security: How Smart Cards and Java Mix," is devoted to Java on smart cards. We decided to include this chapter since Java Cards are likely to show up in millions of consumer wallets in the next few years. Smart card security is really too big an issue to cover in a single chapter, so we focus primarily on the security impact of putting a Java Virtual Machine on a card. Chapter 8 covers six key questions, including: What is a smart card?, Why put Java on a smart card?, and How does the use of Java impact smart card security?
We conclude by covering some of the challenges to mobile code that remain to be conquered. Chapter 9, "The Future of Java Security: Challenges Facing Mobile Code," presents a concise set of six central lessons we have learned during our time in the Java security trenches. We go on to discuss several open research issues that you're likely to hear about again. Finally, we discuss the notion of security assurance, an important strategy in securing Java.
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 disclose those risks-and countermeasures to curtail them-as clearly and objectively as possible. Armed with the knowledge that we present in this book, Java users, site managers, and business decision-makers can make better Java use policies.
