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 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
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.
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
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.
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.