Table Of Content

Securing Java: Getting Down to Business with Mobile Code, Second Edition Gary McGraw and Ed W. Felten John Wiley & Sons, Inc. January 25, 1999 ISBN-10: 047131952X ISBN-13: 978-0471319528 Paperback: 324 pages Buy on Amazon About the Web Edition by Ryan A. MacMichael A little under ten years ago, there was a company betting their livelihood on the popularity of electronic books. They put out a handheld device that cost a few hundred dollars and offered e-books and e-magazines on disk. This was beforetheInternethadbecomeahouseholdnecessityandtheideadidnotgo over very well at all -- they disappeared in less than a year. Why did they go under? For some of the obvious reasons: poor screen resolution, the general clunkiness of the reader, and it just didn't feel right needing batteries to read a book at the beach. It was pretty clear then that electronicbookswerenotgoingtobeaseriouscompetitortothephysicalbook anytime soon. Cliff Stoll felt much the same way, as he talked at length about inSilicon Snake Oil: Second Thoughts on the Information Highway. I'd say, unequivocally, that the world is not ready for a handheld device like the one above to out-and-out replace the physical book. However, with the extreme popularity of the Web, the release of an online book is a wonderful complement to the release its physical counterpart: ☞Books don't have a satisfying search capability built into them. The index is usually somewhat helpful and a "top-level" navigation system like the table of contents works to a point, but what about when you're looking for that one small section you read a few days ago? The online book allows a reader to jump on the Net and run a quick search through the entire text. ☞From a promotional standpoint, the online book makes deciding to purchase a text online as easy as reading a few passages of the same book from a physical store. Unlike reading selected passages that book mega-sites like Amazon may provide, having the entire text of yourbookonlineletsconsumersseeforthemselveswithoutleaving their home if it really fills their needs before ordering the paper version online. ☞And the importance of a book existing in a hypertexted Web space can't be stressed enough. The very foundation of the WWW is the ability to use hypertext to a degree previously only dreamed of. The phrase "see also: section x in chapter y" works as a link directly to the cross-reference. A categorized list of links (like those in the appendices of this book) is much more accessible and usable, especially when accompanied by a searchable index. And details of afootnoteorcitationcanbeeasilyaccessedthroughanunobtrusive pop-up window. When you add a search facility, worldwide accessibility, and hypertext to a physical book, the additional value is immeasurable. With a site supporting a technical book likeSecuring Javathe benefits are immediately obvious: ☞Searching the online text for "smart card SSL" is a lot quicker than jumping to the table of contents, choosing chapter eight, and then figuring out manually which section(s) refer to the use of SSL with Java smart cards. ☞Now imagine you're at work and you read a feature in one of the weekly techie trade rags about Securing Java. You swing by Amazon and there's minor information, but not much, and you doubt that you'llhavetimetogotoBordersonthewayhometotakealookatthe book.Swingbythewebsiteandyoucanthumbthroughthebook,so tospeak,asifyouwerelounginginoneofthosecomfychairsatthe book superstore. ☞Lastly, in a book like Securing Java, direct links to lengthy research papers provide an added dimension a URL on paper can't provide. Being able to quickly download a postscript version of a doctoral thesis will add a new dimension to what you're reading online in another window. The process of writing a book, especially a non-fiction text, is changing -- the authormustconsiderprovidingweb-basedresourcesasseriouslyasaddingan appendix. Whether these online resources are a list of links, text corrections andupdates,orprovidingafull,searchableonlinetextdependsonthenature of the book, but it's clear that at least some level of support and information beyond traditional paper publishing is becoming necessary and hopefully through example, theSecuring Javasite will help clarify this importance. We hope you find the online version of Securing Java a useful supplement to thephysicaledition.Weinviteyoutoshowyoursupportfortheeffortputinto the online version by purchasing the book. Ryan MacMichael is the Webmaster at Cigital in Dulles, VA, and designed the onlineversionofSecuringJava.HehasbeenpreviouslypublishedinBBSCallers Digest and spends too much of his spare time on perhaps the world's largest personal Web site. You can reach Ryan with any problems or comments at [email protected]. Table of Contents Preface Chapter1. Mobile Code and Security: Why Java Security is Important Chapter2. The Base Java Security Model: The Original Applet Sandbox Chapter3. Beyond the Sandbox: Signed Code in JDK 1.2 Chapter4. Malicious Applets: Avoiding the Common Nuisances Chapter5. Attack Applets: Exploiting Holes in the Security Model Chapter6. Securing Java: Improvements, Solutions, and Snake Oil Chapter7. Java Security Guidelines: Developing and Using Java More Securely Chapter8. Java Card Security: How Smart Cards and Java Mix Chapter9. The Future of Java Security: Challenges Facing Mobile Code Appendix A. Frequently Asked Questions Appendix B. Java Security Hotlist Appendix C. How to Sign Java Code References Preface Javahasgrownbyleapsandboundssinceitsintroductionin1996,andisnow amongthemostpopularcomputingplatformsontheplanet.Javahasevolved 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 aboutmobilecodeandsecurity,andincludesmanythingswehavediscovered 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 itwasintroduced.Nolongersimplyaclient-sidelanguageforapplets,Javacan nowbefoundoneverythingfromenterpriseapplicationserverstoembedded 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 keptfourgroupsinmindaswewrotethisbook:Webusers,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. Javaisonlyonekindofmobilecodeamongmany.Othersystemsimmersedin thesamesecuritydilemmaincludeActiveX,JavaScript,andWordMacros.Itis essentialnottogetthewrongmessagefromthisbook.OurfocusonJavaisno accident.WebelieveJavaisthemostviablemobilecodesystemcreatedtodate. Don'tbelievethatthroughourworkweimplythatothersystemsareanymore secure than Java. Just the opposite is true. WiththeintroductionofcodesigningtoJava(inJDK1.1)anditsenhancement 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 morefunctionality,whichmostbusinessesanddevelopersseemtoneed,butit isbadifyouarechargedwithmanagingsecurityrisks.Forminganintelligent Javausepolicyismoreimportantthanever,butdoingsoismorecomplicated than it used to be. The computer field moves so fast that people have begun to refer to Internet timetograpplewithitsconstantlyacceleratingspeed.Threemonthsisayear inInternettime.Javaisdirectlyinvolvedinthespeedofthefield,andhasdone itssharetomakethingsmoveevenmorequickly.Onetrickyaspectofwriting atopicalbookrelatingtotheWebisfiguringoutwhentostoptheaction.This process can be likened to freeze-framing a picture of a movie. In that sense, thisbookisasnapshotofJavasecurity.Wehopewehavesucceededinmaking itausefulwaytolearnaboutJavasecurity.Forup-to-dateinformation,seethe book's companion Web site at securingjava.com. As we went to press, Sun Microsystems renamed JDK 1.2 and called it Java 2. Wehaveattemptedtousecorrectversionnumbersthroughoutandapologize for any confusion. Chapter1, "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 securityisnowasimportanttobusinesspeopleandsystemadministratorsas itistoWebusersandJavadevelopers.Fortheuninitiated,Chapter1providesa quickandcursoryintroductiontoJava.Pointersareprovidedtomorethrough 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 distinctionbetweenappletsandapplicationshasbeensupercededbyconcerns about trust. It turns out that under the Java 2 architecture, applets can be completely trusted and applications can be completely untrusted. In fact, everykindofJavacodecanbedoledoutdifferentamountsoftrust,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. Chapter2, "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 untilcodetakesoncompletetrustandisawardedfullrunoftheentiresystem. Chapter3, "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 transformationwiththeadditionofaccesscontrol.Itisnowpossibletocreate 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 mobilecodethaneverbefore,butitalsointroducesamajornewrisktoJava: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.JDK1.1andJava2restonthenotionoftrust,whichleveragesthe technological power of code signing. Understanding the new model requires understandingthewaycodesigningandtrustinteract,anddiscountingsome of the common myths associated with it. Chapter3 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.) Chapter4, "Malicious Applets: Avoiding a Common Nuisance," begins to discuss what happens when the Java security model is abused by hostile applets.Hostileappletscomeintwoforms:verydangerousattackappletsthat involve security breaches, and merely annoying malicious applets that are moreofanuisancethananythingelse.Chapter4isallaboutmaliciousapplets. 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. Chapter5, "Attack Applets: Exploiting Holes in the Security Model," delves more deeply into the Java security model by focusing attention on some of thewell-publicizedsecurityholesthathavebeendiscovered.Thisiswhereour discussion of hostile applets turns more serious. Securing Java is a difficult job, especially when it comes to implementing complicated models. Attack appletshavebeencreatedinthelabthatexploittheholeswediscuss.Someof theholesaresimpleimplementationbugs,whileothersindicatemoreserious designflaws.ThegoodnewsisthatSunandotherlicenseestakeJavasecurity 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. Chapter6, "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. Fixingsomeofthesewouldcertainlyimprovethemodel.High-levelconcerns addressedinChapter6includeprogramminglanguageissues,formalanalysis of Java, applet logging, trust, decompilation, applet monitoring, and policy management. Hopefully, some of the high-level concerns we raise will eventuallybeaddressedintheJavaplatformitself.Inthemeantime,anumber of third-party vendors are eager to help. The second goal of Chapter6 is to introducetheplayersbrieflyandtodiscusswhatrisksthird-partyvendorscan andcannotaddress.Thecomputersecurityfieldhasitsshareofsnakeoil,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 Chapter7, "Java Security Guidelines: Developing and Using Java More Securely." This chapter presents