Table Of ContentSecuring 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
rmacmich@cigital.com.
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
