IDWILEY
`
`Getting Down
`to Business with
`Mobile Code
`
`Gary McGraw
`Edward W. Felten
`
`Page 1 of 121
`
`GOOGLE EXHIBIT 1020
`
`

`

`Praise for Securing Jovo ...
`
`.. This second edition is mandatory up-to-date reading for every user and devel(cid:173)
`oper of Webware. Its eye-opening analysis of the security risks provides timely
`realism amidst an otherwise mad dash to universal Net use:'
`-Peter G. Neumann
`Principal Scientist
`Computer Science Lab, SRI International
`Moderator of the Risks Forum
`Author of Computer-Related Risks
`
`"This book cuts through the hype and clears up the confusion surrounding Java
`and security:'
`-Bill Venners
`Author of Inside the Java Virtual Machine
`
`"McGraw and Felten give Java's designers their due for trying to create a secure
`Internet programming language, but they cut through a lot of the hype-both posi(cid:173)
`tive and negative-about how secure it really is. Since Java pervades many aspects
`of Internet commerce, knowing the true risks is important for anyone who plans
`to do business on the Net:'
`-David Carr
`Senior Editor
`Internet World
`
`"Security is a part of modem networking that often gets ignored until it's too late ....
`Gary and Ed's book is a clear explanation of the situation, chock full of details and
`useful advice. A must-read book for anyone who is considering mobile code as part
`of their mission-critical infrastructure:'
`-Marcus J. Ranum
`CEO, Network Flight Recorder, Inc.
`
`Page 2 of 121
`
`

`

`Prai~e for the First edition: Java Security ...
`
`"One of the best treatments of Java security issues I have ever had the pleasure to
`read. The advice offered in this book is sound and reasonable:'
`Thomas A. Longstaff
`Manager of Research & Development
`CERT Coordination Center
`
`"A provocative and useful discussion of security issues around Java and the
`Internet to date"
`Li Gong, Ph.D.
`Java Security Archited
`Java Soft
`
`~is book is mandatory reading for every user and developer of webware. Its
`eye-opening analysis of the security risks provides timely realism amidst an other(cid:173)
`wise mad dash to universal net browsing.
`Java is hot. Java is cool.
`Its use is riddled with risks that fool.
`Jovo Security takes us all back to school:'
`Peter G. Neumann, Principal Scientist, Computer Science Lab,
`SRI International; Moderator of the Risks Forum; Author of
`Computer-Related Risks
`
`" ... a tour de force .... clear and comprehensive discussions of the Java security
`model and various problems with its numerous implementations. It will make for
`enjoyable, and profitable, reading by all system administrators, webmasters, and
`programmers--particularly in the corporate world. If you surf, or if you maintain a
`website, this book is for you. This is an enormously useful book. Buy it!
`Gregory J. E. Rawlins,
`Associate professor, Indiana University;
`author of Moths to the Flome: The Seductions of Computer Technology
`
`"McGraw and Felten do a great job of presenting a thorough and understandable
`treatment of the complex security issues surrounding Java and other Web-related
`languages .... This book is a must for anyone who uses Web browsers and related
`software, written by the experts who have practically defined the field of Java
`security:'
`Michael Shoffner, Java developer, Prominance.com
`
`Page 3 of 121
`
`

`

`Securing Java:
`Getting Down to Busin~ss
`with Mobile Code _
`
`WILEY COMPUTER PUBLISHING
`
`John Wiley & Sons, Inc.
`New York • Chichester • Weinheim • Brisbane • Singapore • Toronto
`
`Page 4 of 121
`
`

`

`For our parents.
`
`Publisher: Robert Ipsen
`Editor: Marjorie Spencer
`Assistant Editor: Margaret Hendrey
`Managing Editor: Frank Grazioli
`Composition: Benchmark Productions Inc., Boston
`Designations used by companies to distinguish their products are often claimed as
`trademarks. In all instances where John Wiley & Sons, Inc., is aware of a claim, the
`product names appear in initial capital or ALL CAPITAL LEITERS. Readers, however
`should contact the appropriate companies for more complete information regarding
`trademarks and registration.
`This book is printed on acid-free paper. i§
`Copyright© 1999 by Gary McGraw and Edward W. Felten. All rights reserved.
`Published by John Wiley & Sons, Inc.
`Published simultaneously in Canada.
`No part of this publication may be reproduced, stored in a retrieval system or trans(cid:173)
`mitted in any form or by any means, electronic, mechanical, photocopying, recording,
`scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976
`United States Copyright Act, without either the prior written permission of the Pub
`lisher, or authorization through payment of the appropriate per-copy fee to the Copy(cid:173)
`right Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax
`(978) 750-4744. Requests to the Publisher for permission should be addressed to the
`Permissions Department, John Wiley & Sons, Inc., 605 Third Avenue, New York, NY
`10158-0012, (212) 850-6011, fax {212) 850-6008, E-Mail: PERMREQ@ WILEY.COM.
`This publication is designed to provide accurate and authoritative information in
`regard to the subject matter covered. It is sold with the understanding that the pu
`lisher is not engaged in professional services. If professional advice or other expert
`assistance is required, the services of a competent professional person should be
`sought.
`Library of Congress Cataloging-in-Publication Data:
`McGraw, Gary, 196~
`Securing Java : getting down to business with mobile code
`McGraw, Edward W. Felten, - 2nd ed.
`P· em.
`Originally published under title: Java security. 1997.
`Includes bibliographical references and index.
`ISBN 0-471-31952-X (paper/online : alk. paper)
`1. Java (Computer program language) 2. Computer security.
`I. Felten, Edward, 1963-
`IT. McGraw, Gary, 196~ Java
`.
`security.
`ill. Title.
`QA76.73.J38M354 1999
`005.8-dc21
`
`98-49151
`CIP
`
`Printed in the United States of America.
`
`10 9 8 7 6 5 4 3 2 1
`
`Page 5 of 121
`
`

`

`Chapter 1
`
`Chapter 2
`
`Mobile Code and Secu~ Why Java Security
`Is Important
`Who Cares?
`Mobile Code
`The Power of Networking
`Downloading Code: Not a New Problem
`Java in a Demitasse
`Securing Java
`How Does Java Security Stack Up?
`Where to Find More Information on Java
`Mobile Code Has Its Price
`Assessing the Risks
`The Base Java Security Model: The Original
`Applet Sandbox
`Potential Tiueats
`What Untrusted Java Code Can't Do
`What Untrusted Java Code Can Do
`The Java Language and Security
`The Tiuee Parts of the Default Sandbox
`The Verifier
`The Class Loader Architecture
`The Security Manager
`Different Classes of Security
`Type Safety
`Browser-Specific Security Rules
`The Fundamental Tradeoff
`Is There Really a Java Security Policy?
`
`1
`2
`5
`7
`13
`15
`24
`25
`31
`33
`35
`
`37
`38
`46
`48
`48
`50
`52
`59
`67
`71
`74
`77
`78
`78
`
`Page 6 of 121
`
`

`

`[ vi 1
`
`Chapter 3
`
`Chapter 4
`
`Chapter 5
`
`Chapter 6
`
`Beyond the Sandbox: Signed Code and Java 2
`What's the Main Goal?
`Security Enhancements inJDK 1.1
`Signed Code
`Trust
`An Introduction to Java 2 Security
`Access Control and Stack Inspection
`New Security Mechanisms in Sun's Java 2
`Outside the Sandbox
`Malicious Applets: Avoiding a Common Nuisance
`What Is a Malicious Applet?
`Annoying Applets
`Denial of Service
`Opening Untrusted Windows
`Stealing Cycles
`Forging Mail
`Killing Off the Competition
`Malicious Applets on the Web
`The Implications
`Attack Applets: Exploiting Holes in the Security Model
`Implementation Errors or Specification Errors?
`Attack Applets
`What Applets Aren't Supposed to Do
`A Chronology of Problems
`Jumping the Firewall
`Slash and Burn
`You're Not My Type
`Applets Running Wild
`Casting Caution to the Wind
`Tag-TeamApplets
`Big Attacks Come in Small Packages
`Steal This IP Number
`Cache Cramming
`Virtual Voodoo
`The Magic Coat
`Verifying the Verifier
`The Vacuum Bug
`Look Over There
`Beat the System
`What These Problems Teach Us
`Securing Java: Improvements, Solutions, and Snake Oil
`Improving the Platform
`Writing Safer Code: A Defensive Stance
`Third-Party Solutions or Snake Oil?
`Risks That Third-Party Vendors Can Address
`Risks That Third-Party Vendors Can't Address
`Assess Your Risks
`
`81
`82
`83
`88
`92
`95
`97
`101
`113
`115
`117
`121
`127
`130
`132
`133
`135
`136
`138
`139
`140
`143
`143
`144
`147
`153
`156
`158
`163
`165
`167
`169
`171
`172
`172
`174
`177
`178
`182
`184
`187
`188
`199
`200
`204
`208
`211
`
`Page 7 of 121
`
`

`

`Chapter 9
`
`Appendix B
`
`Chapter 7
`
`Chapter 8
`
`Appendix A
`
`Java Security Guidelines: Developing and
`Using Java More Securely
`Guidelines for Java Developers
`Guidelines for Java Users
`Guidelines Are Never Perfect
`Java Card Security: How Smart Cards and Java Mix
`Java Security Goes Both Ways
`What Is a Smart Card?
`Why Put Java on a Smart Card?
`How Can Java Fit on a Card?
`How Secure Are Smart Cards?
`What Role Can Smart Cards Play in
`E-Commerce Systems?
`How Does the Use of Java Impact Smart Card Security?
`Managing Risks
`The Future of Java Security:
`Challenges Facing Mobile Code
`Lessons from the Trenches
`Challenges for Secure Mobile Code
`Software Assurance for Java
`Should You Use Java?
`Frequently Asked Questions:
`Java Security Java versus ActiveX
`Java Security
`Security Tradeoffs: Java versus ActiveX
`The Java Security Hotlist
`Books
`Researchers
`FAQs
`Papers
`Talks I Articles
`Hostile Applets
`Commercial
`Mostly Harmless
`Appendix C How to Sign Java Code
`Signing Classes with the Netscape Object Signing Tool
`Signing Java Applets with Microsoft's Authenticode
`Comparing Authenticode to Netscape Object Signing
`Signing Code with Sun's JDK l.l.x
`Differences Between Netscape Object Signing and
`JDK l.l.x javakey
`Signing Code with Sun's Java 2
`Differences betweenJDK 1.1 Code Signing
`and Java 2 Code Signing
`In Conclusion
`References
`Index
`
`vii
`
`213
`214
`221
`226
`227
`228
`229
`231
`232
`233
`239
`
`240
`244
`
`245
`245
`247
`251
`252
`
`255
`255
`260
`265
`266
`267
`269
`271
`274
`277
`279
`281
`283
`284
`292
`297
`297
`303
`303
`303
`311
`311
`312
`313
`319
`
`Page 8 of 121
`
`

`

`Java has grown by leaps and bounds since its introduction in 1996, and is now
`
`among the most popular computing platforms on the planet. Java has evolved and
`changed so much that at a mere two-years old, our original work, Java Security:
`Hostile Applets, Holes, and Antidotes, found itself in serious need of revision and
`expansion. This book is the result of several years of thinking about mobile code
`and security, and includes many things we have discovered while working on
`real-world systems with businesses and government agencies. Our goal is to
`present enough information to help you separate fact from fiction when it comes
`to mobile code security.
`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 grand(cid:173)
`mothers 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 under(cid:173)
`standing 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.
`
`viii
`
`Page 9 of 121
`
`

`

`ix
`
`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 essen(cid:173)
`tial 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 I functionality tradeoff has moved significantly toward func(cid:173)
`tionality, 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 mak(cid:173)
`ing 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 intro(cid:173)
`duction 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 dis(cid:173)
`cussing why the once-important distinction between applets and applications has
`been superceded by concerns about trust. It turns out that under the Java 2 archi(cid:173)
`tecture, 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 pop(cid:173)
`ular 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," exam(cid:173)
`ines 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 antago-
`
`Page 10 of 121
`
`

`

`nism. We then discuss Java's programming-languages approach to security and
`introduce the three parts of the original applet sandbox. These include the Verifier,
`~~~~~~~~~~~~~~~~~~
`idea that Java security fundamentally relies on ensuring type safety. The base sand(cid:173)
`box 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 pol(cid:173)
`icy for mobile code written in Java and have the Java system itself enforce the pol(cid:173)
`icy. 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(cid:173)
`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. Under(cid:173)
`standing 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. (Appen(cid:173)
`dix 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-pub(cid:173)
`licized 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 imple(cid:173)
`mentation 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 posi(cid:173)
`tively. 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
`
`Page 11 of 121
`
`

`

`xi
`
`these would certainly improve the model. High-level concerns addressed in Chap(cid:173)
`ter 6 include programming language issues, formal analysis of Java, applet log(cid:173)
`ging, 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 guide(cid:173)
`lines: 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 secu(cid:173)
`rity 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 deci(cid:173)
`sions regarding the use of Java (especially in business and other mission-critical
`systems) requires some know ledge 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.
`
`Acknowledgments
`
`This book is a collaborative effort in more ways than one. Not only did the au(cid:173)
`thors work together closely, but we also sought input from many other people.
`We are grateful for the help we received.
`Reliable Software Technologies (www.rstcorp.com) remains a great place to work.
`The intellectually stimulating environment makes going to work interesting and
`fun. Many people at RST read drafts of the book or helped in other ways. They
`include John Viega (intrepid proofreader and co-author of the code-signing tutorial
`
`Page 12 of 121
`
`

`

`xii
`
`in Appendix C), Tom O'Connor (who also read the entire manuscript more than
`once and co-wrote the code-signing tutorial), Anup Ghosh (fellow security
`researcher), Peggy Wallace (travel, anyone?), Lora Kassab (one-time RST intern
`whose code from the first edition lives on), Jeff Payne (RST's forward-thinking
`CEO), Jon Beskin, Matt Schmidt, Brad Arkin, Andi Bruno (who herds the market(cid:173)
`ing cats and makes us be nice), and JeffVoas (who continues to lead RST's excellent
`research group by example).
`The members of Princeton University's Secure Internet Programming Team
`(www.cs.princeton.edu/sip) also provided valuable input. Besides wading through
`several drafts, the Princeton team was responsible for raising many of the key
`issues in Java security. Special thanks to Drew Dean and Dan Wallach (cofounders
`of the Princeton team) and Dirk Balfanz. Dan is now a professor at Rice University.
`Drew is a research scientist at Xerox PARC. Princeton's Computer Science depart(cid:173)
`ment provides a wonderful environment for discovering and exploring new
`research topics.
`We would also like to thank Tom Cargill, independent consultant and discoverer
`of two security flaws; David Hopwood, discoverer of several attack applets; Mark
`LaDue, creator of the Hostile Applets Home Page (keep 'em honest, Mark); Dennis
`Volpano of the Naval Postgraduate School; Tom Longstaff, research director at the
`CERT Coordination Center; Roland Schemers, JavaSoft security implementation
`wizard (who helped with code-signing tool questions); Marianne Mueller, Java
`developer, security expert, and long-suffering target of press inquiries at JavaSoft;
`Jim Roskind, Netscape's Java security expert; Andrew Herbert, APM's Chief Sci(cid:173)
`entist in the real Cambridge; Ken Ayer, chip card security manager at Visa; Don
`Byrd, UMass research associate and careful proofreader of the first edition;
`Hideyuki Hayashi, who translated the first edition into Japanese (and did an
`excellent job according to friends at Sumitomo in New York); Kieran Murphy, edi(cid:173)
`tor at developer.com; Chuck Howell, now at Mitretek; and Mike Shoffner, Java
`developer at Prominence Dot Com. Li Gong, security architect at JavaSoft, has
`been a particularly valuable help, both as a research colleague and as a sane point(cid:173)
`of-view atJavaSoft. More power to you, Li.
`Wiley's staff did an excellent job shepherding this book through the editing and
`production process. Special thanks to Marjorie Spencer and Frank Grazioli, who
`went out of their way to make this project go smoothly. Thanks to Margaret Hen(cid:173)
`drey for playing fast and loose with extensions (don't tell anybody). Also thanks to
`the rest of the team at Wiley.
`Finally, and most importantly, we're grateful to our families for putting up with us
`while we worked on the book, again. Amy Barley, Jack, and Eli seem to have
`adjusted to Gary's persistent book-writing. Laura Felten and Claire suspect that
`Ed's book-writing has become an addiction. Without the support of our families,
`this book would not have been possible.
`
`Page 13 of 121
`
`

`

`Mobile Code and Secu
`Why Java Securi~
`Is Important
`
`Java security is more important than ever. Since its introduction in 1995, Java
`
`has become one of the most popular development platforms on the planet. In
`fact, Java has been widely adopted more quickly than any other computer
`language. It now easily tops the list of preferred platforms for Internet-savvy
`mobile code. There are tens of thousands of Java developers (some say hun-
`dreds of thousands), and demand for Java skills appears to be growing. Java
`is definitely here to stay.
`
`Java holds great promise as a platform for component-based software,
`embedded systems, and smart cards. This means Java is poised to play an
`important enabling role in e-commerce as these systems move from ether(cid:173)
`ware to reality. Java components (aka JavaBeans) are appearing at a rapid
`pace and encapsulate critical functionality for transaction-based systems.
`Java smart cards fore-commerce will debut soon.
`
`But what of the hue and cry over security? Should people be so concerned
`about the security implications of Java that they disable Java in their
`browsers? Should developers avoid using Java in their systems in favor of
`other languages like C++? Should system administrators block Java content
`at the firewall (or better yet, can they)? Should business people avoid Java
`because of security problems? These are the some of the questions this book
`answers. The answers are nontrivial, and the issues are as complex as they
`are important.
`
`1
`
`Page 14 of 121
`
`

`

`- ~l
`
`Java security is important to a number of distinct sets of people:
`
`Web users, including one of the authors' 89-year-old grandmother, need to
`understand the risks of using a Java-enabled browser.
`Developers of Java code that lives and works on the Internet need to keep
`security in mind when they are writing programs.
`System administrators need to think carefully about how mobile code, includ(cid:173)
`ing Java, impacts the security of the systems they run.
`Business people need to understand what Java security risks are so they can
`make informed business decisions based on fact and not fiction.
`
`As you can see, Java security issues are multifaceted. This book has useful
`information for all four groups, whose interests overlap in many ways.
`
`Java security is a hot topic, but that does not make it an easy one. By itself,
`computer security is not well understood. Throw Java into the mix and
`things become even murkier. There is much confusion and misinformation
`floating around about Java and security. Beware of snake oil, impossible
`claims, and consultants who pretend to have all the answers. Also be aware
`that major vendors are just as capable of misinformation as fly-by-night com(cid:173)
`panies. Skepticism, Rene Descartes' 300-year-old philosophical insight, is
`strangely relevant to computer security at the turn of the millennium. In fact,
`skepticism turns out to be an excellent strategy. Ask hard questions; you
`might be surprised by the answers.
`
`Browser Beware
`The most pressing security concerns surrounding Java impact millions of
`people-that is, anyone who browses the Web. Given that there are tens of
`millions of Netscape Navigator and Microsoft Internet Explorer users, the
`client security issue is no minor detail. 1 It turns out that a majority of the
`users of these browsers are also Java users, whether they know it or not. Java
`is built in to Netscape Navigator and Internet Explorer, so if you use either of
`these products, you are a Java user.
`
`Just as all Internet users are taking security risks, all Java users are taking
`security risks. Because of the way Java works, computer security issues are a
`fundamental concern. Most Java code is automatically downloaded across
`
`1 Both the popular Netscape Navigator browser and the Microsoft Internet Explorer browser
`are capable of running Java applets.
`
`Page 15 of 121
`
`

`

`3
`
`the network and runs on your machine. This makes it very important to limit
`the sorts of things that Web-based Java programs can do. Silnply put, a hos(cid:173)
`tile Java program could trash your machine. Because Java is inherently Web(cid:173)
`based, it provides crackers with an easy way to ilnplement a Trojan Horse-a
`program that may seem innocent enough on the surface, but is actually filled
`with well-armed Greeks. Also of concern is the problem of computer virus
`propagation. Fortunately, the creators of Java have made a good effort to pro(cid:173)
`tect users from these hazards. For example, writing a Web-based Java virus as
`an applet would be very hard. (Writing a Microsoft Word macro virus like the
`concept virus is, by contrast, easy.) Because mobile code security is new, diffi(cid:173)
`cult, and complicated, Java's masters have not always been successful at pro(cid:173)
`tecting everyone all the time.
`
`One goal of this book is to educate Java users about the risks that they incur
`by surfing the World Wide Web with Java-enabled browsers. This chapter
`provides a gentle introduction to Java and explains why Java is potentially
`dangerous.
`
`Developer Concerns
`Java security is essential to developers as well. As a platform, Java has much
`to offer in terms of security:
`
`• Java has advanced cryptography Application Program Interfaces (APis)
`and class libraries.
`• Java includes language-level security mechanisms that can help make
`developing secure code easier.
`• Some aspects of Java that make it more difficult to write insecure (unsafe)
`code.
`
`This book explains how to use the security features built in to the Java envi(cid:173)
`ronment inside your own programs.
`
`That's not to say that developing secure programs with Java is trivial or auto(cid:173)
`matic. Anyone who reads the newspapers or the trade press can see how
`often skilled programmers write code with security bugs. You can make
`almost as many gaffes developing security-critical code in Java as in any
`other language. Because of Java's security APis and its position as a leading
`e-commerce platform, it is likely that Java will be used to carry out some very
`important activities. That means developers need to learn as much as they
`can about Java security. Know your enemy. Think about what might confront
`your code in terms of malicious attacks. Mitigate risks by designing, coding,
`and testing carefully.
`
`Page 16 of 121
`
`

`

`I 4 1
`
`A second goal of this book is to teach Java developers and project managers
`about the sorts of things that will confront their code in "the wild." If you' re
`a seasoned Java developer (something that it was impossible to be a mere
`handful of years ago), this book will show you in great detail how the secu(cid:173)
`rity model works. There are lessons to be learned from the Java attacks we
`cover. After all, like you, Java's designers and developers were serious about
`what they