Securing Java: Getting Down to Business with Mobile Code / Edition 2

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 94%)
Other sellers (Paperback)
  • All (14) from $1.99   
  • New (1) from $58.77   
  • Used (13) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2008

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.


Ships from: Chicago, IL

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by


Information Security/Java "This book is mandatory reading for every user and developer of Webware." -Peter G. Neumann, Moderator of the Risks Forum, from his review of the first edition Securing Java Java security is more important now than ever before. As Java matures and moves into the enterprise, security takes a more prominent role. But as Java evolves, its security issues and architectures get more complicated. Written by the world's leading experts on mobile code security, this updated and expanded edition of the groundbreaking guide to Java security includes lessons for Web users, developers, system administrators, and business decision-makers alike. This book navigates the uncharted waters of mobile code security and arms the reader with the knowledge required for securing Java. It provides in-depth coverage of:
* The base Java security sandbox, made up of the Verifier, Class Loaders, and the Security Manager
* Code signing, stack inspection, and the new Java 2 security architecture
* The pros and cons of language-based enforcement models and trust models
* All known Java security holes and the attack applets that exploit them
* Techniques commonly used in malicious applets
* Twelve rules for developing more secure Java code, with explicit examples
* Hard questions to ask third-party Java security tools vendors
* Analysis of competing systems for mobile code, including ActiveX and JavaScript
* Card Java security, smart card risks, and their impact on e-commerce security
On the companion Web site you'll find:
* The Java Security Hotlist: Over 100 categorized and annotated Java security-related Web links
* An e-mail list to keep subscribers abreast of breaking Java security news
* A complete electronic edition of this book

"--because java code travels from platform to platform, it presents a unique problem to security as there is no known way to block bad code via hardware or filters. --reviews ActiveX & Smartcard security & other solutions."

Read More Show Less

Editorial Reviews

This updated and expanded edition of a guide to Java security (previously titled ) provides in-depth coverage of the base Java security sandbox, the new Java 2 security architecture, language-based enforcement models and trust models, Java security holes and attack applets that exploit them, and techniques commonly used in malicious applets. For developers and business decision makers. Annotation c. by Book News, Inc., Portland, Or.
Jack Woehr

Security by Obscurity

Securing Java, a successor volume by Gary McGraw and Edward W. Felten to their 1997 Java Security, is an ambiguous book. Securing Java is really about insecuring Java. It's about errors, errors of strategy and tactics, errors existential in nature, errors which potentially allow the malevolent cracker to code what is literally a killer Java applet.

McGraw and Felten are part of the security research community. They know whereof they speak and describe the taxonomy of nearly every recorded Java security lapse, whether inherent in Sun's design or resultant from vendor miscues in virtual machine implementation. While many of the holes in the model have already been patched, the emphasis is on what types of things to look for, from what directions one might anticipate finding a security hole. "Security holes can be likened to pitons," the book says, "Sometimes one piton is enough to help a climber make it to the top ... other times, more than one piton may be needed."

Securing Java is excellently edited and designed, a gripping technical "whatdoneit" that should have Dilbert sitting on the edge of his seat. The entire book can also be read on the web at, complete with search engine. The publisher is daringly operating under the theory that you will like what you see and need a copy to carry with you on the airplane. The authors do not believe that the free web version will impact sales of the printed book. In any event, you can order the paper book from the web page.

Overall description is engagingly rich but the discussion of internals is evasive. Securing Java reads like a roman-a-clef thriller where, if the author told you more, "he'd have to kill you."

Having in mind the stunning revelations about intellectual freedom in America that emerged from the experiences undergone by programming gurus like Phil Zimmerman and Jon Gilmore, I asked Gary McGraw about the team's tantalizingly vague literary treatment of a computer science topic.

"We've been criticized by one guy (Rusty Harold) who said we're proponents of security by obscurity," McGraw told me. "We say: We know what happens in practice is that people will write an exploit script, and the ankle biters will use it like mad.

"We published full details of security holes in 1996, yet there has never been an attack applet in the wild. We didn't provide exploit scripts, just described it so you can understand it, so that people in the know with hands-on experience mucking around this stuff can learn how to write protectively, yet so the lazy can't make an exploit script."

Is Java securable?

"The security situation is very tricky," says McGraw. "The goal is to inject [a] lot of reality into the discussion. The market is ripe for snake oil. People treat security as an add-on feature. Security doesn't work this way; it's like reliability, dependability, the other-ilities.

"Ships used to sink in [the] 1800s, then they built the unsinkable ship which sank, which was big news more than a lot of other ships that sank. That's 'the Titanic effect.' A language comes out, they say, 'Java is secure.' The research community took that as a challenge.

"But Java is by far and away the most reasonable approach to attempting to secure mobile code. I was under the false hope in 1995 that Java would be better than it is."

Much of Securing Java is educational; there are also practical suggestions. Chapter 7, "Java Security Guidelines," presents 12 rules for Java developers and a lengthy series of guidelines for Java users. The appendices cover, among other things, URLs to sites relevant to Java security and a long list of frequently asked questions about Java security (the Java Security FAQ).

Coauthor Ed Felten is known to the general public as the expert witness for the U.S. Department of Justice who, in the Microsoft antitrust trial, noticed the discrepancy in the video because he wrote the program to remove IE from Win95. This became known as "to Feltenize" a Win95 machine. McGraw recounts that over beer one evening several team members took turns offering alternative definitions of "to Feltenize," definitions which, unfortunately, McGraw could not precisely recall during our conversation.

Are the authors leveling with us? Perhaps one needs experience studying the chess literature to assess Securing Java. Books on the chess openings strive earnestly to convey the overarching positional considerations inherent across vast numbers of possible games, all arising from the same few opening moves. At the same time, authors of chess books avoid giving away the specific moves they plan for the next championship cycle.

McGraw and Felten admit they are holding back. But what they have to say is, if one is concerned with securing Java, worthy of hearing, especially since they write so well.
— Dr. Dobb's Electronic Review of Computer Books

Read More Show Less

Product Details

  • ISBN-13: 9780471319528
  • Publisher: Wiley
  • Publication date: 1/22/1999
  • Edition number: 2
  • Pages: 324
  • Product dimensions: 7.45 (w) x 9.16 (h) x 0.81 (d)

Meet the Author

GARY McGRAW is Vice President and Senior Research Scientist with Reliable Software Technologies and an international authority on Java security. Dr. McGraw is the author of over 50 peer-reviewed technical publications, consults with major e-commerce vendors including Visa, and is the principal investigator on several U.S. government research grants. EDWARD W. FELTEN is Professor of Computer Science at Princeton University where he leads the world-renowned Secure Internet Programming team. Professor Felten discovered many of Java's security holes and is actively involved in designing more secure approaches to mobile code.
Read More Show Less

Read an Excerpt

Chapter 4: Malicious Applets

Chapter 2, "The Base Java Security Model: The Original Applet Sandbox," and Chapter 3, "Beyond the Sandbox: Signed Code and Java 2," explain how Java 2's security system works. This chapter and the next explain how it doesn't. Unfortunately, it is entirely possible to (mis)use Java, especially in its applet form, as a vehicle for attacking systems. Language-based security controls like those found in Java make writing a hostile applet more difficult than it might be otherwise, but they don't make it impossible. (Recall that Java security stacks up favorably against competing mobile code systems like ActiveX, as we discussed in Chapter 1, "Mobile Code and Security: Why Java Security Is Important.") Applets that misbehave and do something that their users don't want to happen are called hostile applets.

There are two varieties of hostile applets: malicious applets and attack applets. The names of the two classes make it clear which is the more serious variety. Fortunately, attack applets are not commonly encountered on the Web; in fact, no attack applets have been seen to date in the wild (that is, outside the labs in which they were created). That's not to say that attack applets are not real. They are. Attack applets are real applets, written in everyday Java, that work against popular browsers such as the one you use. Attack applets have been created and extensively tested in the laboratory. (We return to the subject of attack applets in Chapter 5, "Attack Applets: Exploiting Holes in the Security Model.") There is, however, another more pervasive kind of hostile applet, notas serious a security concern, but still worthy of attention-the malicious applet.

Unlike their attack applet cousins, malicious applets have escaped the lab. Such realities make it necessary for all users of Java-enabled browsers (and their trusty system administrators) to be aware of Java security threats. Simply surfing over to a Web page containing a hostile applet allows it to invade your machine with its malicious code. This chapter explores many malicious applets, ranging from the merely annoying to the more seriously disturbing.

Near the beginning of Chapter 2, classes of potential Java threats were discussed. The four classes of attacks named were system modification attacks, invasion of privacy attacks, denial of service attacks, and antagonistic attacks Java is a powerful enough language that, without security constraints placed on applets, it is possible to implement all four such classes of attacks. The Java security model was designed to thwart those threats perceived to be the greatest dangers.

Much ado has been made over Java security problems, and there have in fact been a number of serious flaws. We detail the truly serious problems in Chapter 5. Such problems result in intrusions that allow arbitrary system modification (effectively, unlimited access). An attack applet based on one of these strategies constitutes a cracker breaking into your machine.

It is true that the very serious attacks of the next chapter require an in-depth understanding of both Java and the Internet. It has been argued that we should feel fairly confident that few people will be able to exploit such esoteric vulnerabilities. That position is a dangerous one to take. One instance of a cracker discovering a novel attack applet will change such statements considerably. Once loose, attack applet information would quickly spread throughout the cracker community. Our job as security researchers is to find security holes and plug them before they are used by dishonest people. Security researchers also work to create such a secure model that holes are very rare. Fortunately, none of the serious attacks have shown up in the form of attack applets, although the possibility looms ominously.

Don't breathe a sigh of relief yet. Tampering with Java security does not always require wizardry. In fact, writing Java code to breach security can be easy. This chapter discusses some simple Java applets gone bad. Such applets are known on the Net as malicious applets. Entire collections are available for anyone interested to see, to adapt, and to use. See, for example:

The Hostile Applets Home Page at www.rstcorp.comlhostile-applets
DigiCrime at
The Java Security Hotlist: Hostile Applets and Other Toys at

The best first defense against these sorts of applets is to learn about them.

What Is a Malicious Applet?

A malicious applet is any applet that attacks the local system of a Web surfer using one of the three less-serious classes of attacks discussed in Chapter 2. Malicious applets involve denial of service, invasion of privacy, and/or annoyance. Malicious applets are written by researchers, crackers, and Net miscreants to harass, annoy, and damage Java users. They can even seriously damage a Java user's machine. Any applet that performs an action against the will of the user who invoked it should be considered malicious.

It is important to emphasize again that use of the term Java user applies equally to Java developers and people surfing the Web with a Java-enabled browser. Using Java does not require any programming, or even possession of the JDK; it is enough to use a Java-enabled browser. Under this definition, most people who surf the Web with Java on are Java users.

Malicious applets exist on the Web today that do the following bad things:

  • Forge mail from you to whomever the evil applet's author chooses, saying whatever they wish while masquerading as you
  • Steal your CPU cycles to perform their own work while your legitimate processes languish
  • Crash your local system by using all available system resources

These activities are both impressive and daunting, and we have only scratched the surface.

There are also malicious applets created simply to annoy. These applets go only a bit too far, lingering at the edge of respectability. These sorts of applets do things like play sound files continuously, set up threads that monitor your Web use, and display unwanted graphics on your screen....

Read More Show Less

Table of Contents

Mobile Code and Security: Why Java Security Is Important.

The Base Java Security Model: The Original Applet Sandbox.

Beyond the Sandbox: Signed Code and Java 2.

Malicious Applets: Avoiding a Common Nuisance.

Attack Applets: Exploiting Holes in the Security Model.

Securing Java: Improvements, Solutions, and Snake Oil.

Java Security Guidelines: Developing and Using Java More Securely.

Java Card Security: How Smart Cards and Java Mix.

The Future of Java Security: Challenges Facing Mobile Code.




Read More Show Less

First Chapter

Java Security Guidelines: Developing and Using Java More Securely

Java security is important to Web users, system administrators, Java developers, and business people. Sun Microsystems and others have worked hard to evolve a Java system with which to create and use more secure code. Java is not immune to security risks, however. As we have seen, designing and implementing a language-based security model is not easy, and mistakes are bound to happen. Given that there is no such thing as a 100-percent secure system (at least if we want that system to do anything useful), how can developers create more secure Java code? And, given that Java developers can't always be counted among the good guys, how can Web users tailor their Web use to be more secure? These are the two major questions this chapter answers. We introduce two sets of guidelines in this chapter: developer guidelines for creating more secure Java code and user guidelines for avoiding risks when using Java. By establishing some simple security guidelines, you can avoid most of the risks discussed throughout this book. Many of the user guidelines have been touched on in other chapters. Here they are consolidated in a complete package. On the other hand, the developer guidelines are completely new material.

Guidelines for Java Developers

This section introduces 12 rules for writing security-critical Java code; 12 rules that all Java developers should abide by. If you are charged with managing a gaggle of Java developers, or if your business relies on the security of Java, make sure your developers follow these rules. These rules have not been sugar-coated for mass consumption.They get fairly technical and require broad knowledge of Java. Although experienced Java developers will understand all of the rules, less-experienced Java developers may have a bit of homework to do. Nevertheless, these rules are important and can make your Java code more secure. The rules listed here were built on the experiences of many people who have generously discussed their experiences in building secure Java code. We are particularly grateful to Andrew Appel, Dirk Balfanz, Drew Dean, and Dan Wallach, of the Secure Internet Programming Team at Princeton, for helping us understand these issues. Others who have contributed significantly to the behind-the-scenes thinking that went into these rules include David Hopwood, Li Gong, and Jim Roskind. The rules are based on much experience in hunting down Java security bugs, and on advice and observations from people who write and review security-critical Java code for a living. Each rule is designed to eliminate an unexpected "gotcha" that you might face. Of course, security is an elusive goal, and following these rules certainly won't provide any guarantee that your code is secure. It is easy to write insecure code that follows these rules. The goal of these rules is not to guarantee security, but to eliminate certain kinds of security attacks that you might not have thought of. If you follow these rules, certain kinds of attacks will be impossible; other kinds will still be possible. So think of these rules as a first step. If you are writing code that may be linked or run in conjunction with untrusted code, then you should definitely consider following these rules. Every attempt was made to keep the rules simple enough that you can treat them as a checklist to be followed in mechanical fashion. That way, you can save your brainpower for other security issues.

Rule 1: Don't Depend on Initialization

Most Java developers think that there is no way to allocate an object without running a constructor. This is not true: There are several ways to allocate uninitialized objects. The easy way to protect yourself against this problem is to write your classes so that before any object does anything, it verifies that it has been initialized. You can do this as follows:

  • Make all variables private. If you want to allow outside code to access variables in an object, this should be done via get/set methods. (This keeps outside code from accessing uninitialized variables.) If you're following Rule 3, you'll make the get and set methods final.
  • Add a new private boolean variable, called initialized, to each object.
  • Have each constructor set the initialized variable as its last action before returning.
  • Have each nonconstructor method verify that initialized is true, before doing anything. (Note that you may have to make exceptions to this rule for methods that are called by your constructors. If you do this, it is best to make the constructors call only private methods.)
If your class has a static initializer, you will need to do the same thing at the class level. Specifically, for any class that has a static initializer, follow these steps:
  • Make all static variables private. If you want to allow outside code to access static variables in the class, this should be done via static get/set methods. This keeps outside code from accessing uninitialized static variables. If you're following Rule 3, you'll make the get and set methods final.
  • Add a new private static boolean variable, called classInitialized to the class.
  • Have the static constructor set the classInitialized variable as its last action before returning.
  • Have each static method, and each constructor, verify that classInitialized is true, before doing anything. (Note: Constructors are required to call a constructor of the superclass or another constructor of the same class as their first action. Therefore, you will have to do that before you check classInitialized. )
Rule 2: Limit Access to Your Classes, Methods, and Variables

Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something non-private only if there is a good reason, and document that reason.

Rule 3: Make Everything Final, Unless There's a Good Reason Not To

If a class or method is non-final, an attacker could try to extend it in a dangerous and unforeseen way. By default, everything should be final. Make something non-final only if there is a good reason, and document that reason. You might think that you can prevent an attacker from extending your class or its methods by declaring the class non-public. However, if a class is not public, it must be accessible from within the same package, and as we shall see, Rule 4 says not to rely on package-scope access restrictions for security. This advice may seem harsh. After all, the rule is asking you to give up extensibility, which is one of the main benefits of using an object-oriented language like Java. When you're trying to provide security, however, extensibility is your enemy; it just provides an attacker with more ways to cause trouble.

Rule 4: Don't Depend on Package Scope

Classes, methods, and variables that are not explicitly labeled as public, private, or protected are accessible within the same package. Don't rely on this for security. Java classes are not closed, so an attacker could introduce a new class inside your package, and use this new class to access the things you thought you were hiding. (A few packages, such as java.lang, are closed by default, and a few JVMs let you close your own packages. However, you're better off assuming that packages are not closed.) Package scope makes a lot of sense from a software-engineering standpoint, since it prevents innocent, accidental access to things that you want to hide. But don't depend on it for security. Maybe we'll get sealed classes in the future.

Rule 5: Don't Use Inner Classes

Some Java language books say that inner classes can only be accessed by the outer classes that enclose them. This is not true. Java byte code has no concept of inner classes, so inner classes are translated by the compiler into ordinary classes that happen to be accessible to any code in the same package. And Rule 4 says not to depend on package scope for protection. But wait, it gets worse. An inner class gets access to the fields of the enclosing outer class, even if these fields are declared private. And the inner class is translated into a separate class. In order to allow this separate class access to the fields of the outer class, the compiler silently changes these fields from private to package scope! It's bad enough that the inner class is exposed, but it's even worse that the compiler is silently overruling your decision to make some fields private. Don't use inner classes if you can help it. (Ironically, the new Java 2 doPrivileged() API usage guidelines suggest that you use an inner class to write privileged code. That's one reason we don't like the doPrivileged() API.)

Rule 6: Avoid Signing Your Code

Code that is not signed will run without any special privileges. And if your code has no special privileges, then it is much less likely to do damage. Of course, some of your code might have to acquire and use privileges to perform some dangerous operation. Work hard to minimize the amount of privileged code, and audit the privileged code more carefully than the rest.

Rule 7: If You Must Sign Your Code, Put It All in One Archive File

The goal of this rule is to prevent an attacker from carrying out a mix-and-match attack in which the attacker constructs a new applet or library that links some of your signed classes together with malicious classes, or links together signed classes that you never meant to be used together. By signing a group of classes together, you make this attack more difficult. Existing code-signing systems do an inadequate job of preventing mix-and-match attacks, so this rule cannot prevent such attacks completely. But using a single archive can't hurt. Some code-signing systems let you examine other classes to see who signed them. If you are using a code-signing system that allows this, you can put code into the static constructors of your classes to verify that the "surrounding" classes have been signed by the same person as expected. Examining signers is one way to avoid the example shown in Figure 7.1. This doesn't completely prevent mix-and-match attacks, since an adversary can still mix together classes that you signed at different times; for example, by mixing version 1 of Class A with version 2 of Class B. If you're worried about this kind of interversion mix-and-match attack, you can put each class's "version stamp" in a public final variable and then have each class check the version stamps of its surrounding classes.

Rule 8: Make Your Classes Uncloneable

Java's object-cloning mechanism can allow an attacker to manufacture new instances of classes you define, without executing any of your constructors. If your class is not cloneable, the attacker can define a subclass of your class, and make the subclass implement java.lang.Cloneable. This allows the attacker to make new instances of your class. The new instances are made by copying the memory images of existing objects; although this is sometimes an acceptable way to make a new object, it often is not. Rather than worry about this, you're better off making your objects uncloneable. You can do this by defining the following method in each of your classes:

public final void clone() throws java.lang.CloneNotSupportedException {

throw new java.lang.CloneNotSupportedException();


If you want your class to be cloneable, and you've considered the consequences of that choice, then you can still protect yourself. If you're defining a clone method yourself, make it final. If you're relying on a nonfinal clone method in one of your superclasses, then define this method:

public final void clone() throws java.lang.CloneNotSupportedException {

super. clone();


This prevents an attacker from redefining your clone method.

Rule 9: Make Your Classes Unserializeable

Serialization is dangerous because it allows adversaries to get their hands on the internal state of your objects. An adversary can serialize one of your objects into a byte array that can be read. This allows the adversary to inspect the full internal state of your object, including any fields you marked private as well as the internal state of any objects you reference. To prevent this, you can make your object impossible to serialize. The way to do this is to declare the writeObject method:

private final void writeObject(ObjectOutputStream out)

throws {

throw new"Object cannot be serialized");


This method is declared final so that a subclass defined by the adversary cannot override it.

Rule 10: Make Your Classes Undeserializeable

This rule is even more important than the preceding one. Even if your class is not serializeable, it may still be deserializeable. An adversary can create a sequence of bytes that happens to deserialize to an instance of your class. This is dangerous, since you do not have control over what state the deserialized object is in. You can think of deserialization as another kind of public constructor for your object; unfortunately, it is a kind of constructor that is difficult for you to control. You can prevent this kind of attack by making it impossible to deserialize a byte stream into an instance of your class. You can do this by declaring the readObject method:

private final void readObject(ObjectInputStream in)

throws {

throw new"Class cannot be deserialized");


As in Rule 9, this method is declared final to prevent the adversary from overriding it.

Rule 11: Don't Compare Classes by Name

Sometimes you want to compare the classes of two objects to see whether they are the same, or you want to see whether an object has a particular class. When you do this, you need to be aware that there can be multiple classes with the same name in a JVM. It is a mistake to compare classes by name since different classes can have the same name. A better way is to compare class objects for equality directly. For example, given two objects, a and b, if you want to see whether they are the same class, you should use this code:

if(a.getClass() == b.getClass()){

// objects have the same class


// objects have different classes


You should also be on the lookout for cases of less-direct by-name comparisons. Suppose, for example, you want to see whether an object "has the class Foo." Here is the wrong way to do it:

if(obj.getClass().getName().equals(" Foo")) // Wrong!

//objects class is named Foo


//object's class has some other name


Here is a better way to do it:

if(obj.getClass() == this.getClassLoader().loadClass(" Foo")){

//object's class is equal to the class that this class calls "Foo"


//object's class is not equal to the class that

//this class calls "Foo"


Note the legalistic comments in the last example. Whenever you use class-names, you are opening yourself up to mix-and-match attacks, as described in Rule 7. You should also know that the Java language forces you to use classnames all the time: in variable declarations, instanceof expressions, and exception-catching blocks. Only the designers of Java can prevent mix-and-match attacks, but you can avoid making the problem worse by avoiding by-name class comparisons.

Rule 12: Secrets Stored in Your Code Won't Protect You

You might be tempted to store secrets such as cryptographic keys in the code for your application or library. Secrets stored in this way are completely accessible to anyone who runs your code. There is nothing to stop a malicious programmer or virtual machine from looking inside your code and learning its secrets. Code obfuscation is another way to store a secret in your code; in the case of obfuscation, the secret is simply the algorithm used by your code. There's not much harm in using an obfuscator, but you shouldn't believe that it provides strong protection. There is no real evidence that it is possible to obfuscate Java source code or byte code so that a dedicated adversary with good tools cannot reverse the obfuscation.

The Take Home Message

Writing secure Java code is very difficult. There is no magic bullet that will solve your security problems; all you can do is think hard (perhaps with help from formal analysis tools) and use prudent engineering practices to minimize risks. Sometimes a pair of objective outside eyes can help. The rules set forth here are intended to describe some prudent engineering practices for writing secure Java code. They won't solve your security problems, but they will reduce the number of ways in which things can go wrong.

Guidelines for Java Users

It is all well and good to talk about what can be done to improve the next version of Java, or how you as a developer can create safer code, but what can a regular Java user do to stay safe? Are there guidelines for safely using Java as it exists today? There are several straightforward things you can do to make your use of Java safer. Most of these are based on good old-fashioned common sense; others require a bit of knowledge about Java. We have compiled a set of guidelines from the other chapters and have organized them here.

  • Know what Web sites you are visiting.
  • Learn as much as you can about Java security.
  • Know your Java environment.
  • Use up-to-date browsers with the latest security updates.
  • Keep a lookout for security alerts.
  • Apply drastic measures if your information is truly critical.
  • Assess your risks.
Know What Web Sites You Are Visiting

The first piece of advice we have is of the common-sense variety: Know what sorts of sites you are visiting with your Web browser. The chances of being attacked by an applet from a large corporate site like are minimal. The chances of suffering an attack while surfing an underground cracker Web page are, of course, much greater.

All dangerous Web sites may not be run by bad guys, however. One interesting cracker strategy might be to hack a Web server in a very public fashion (something that has been done to the U. S. Department of Justice, the U. S. Air Force, and the Central Intelligence Agency, among others [Ghosh, 1998]), but add a twist. The media coverage will cause many thousands of people to surf to the hacked site to "check it out." Here's where an attack applet would do the most damage! Since the Web server has been hacked, the cracker figures, why not install some mobile code that attacks all surfers indiscriminately? All the curiosity seekers thus become de facto targets.

In any case, there are certainly unsafe places on the Web. An analogy may be useful here. Both of the authors are sorry to admit they drive minivans. There are places in a large city such as Washington, D.C. where no one in his or her right mind would drive a minivan. Just as you shouldn't drive your minivan in certain areas of the city, you shouldn't drive your Java-enabled browser to certain areas of the Web.

You can avoid risk-laden Web sites by employing the same strategy you would use when visiting a big city. Use your intuition to assess your environment continually when you surf. If you are tempted to visit some cracker Web sites, do so with Java turned off. (Actually, make sure that all types of executable content are disabled when visiting such sites!)

The Internet and the Web are reflections of society, no more and no less. There are sites that reflect the pinnacle of what people can achieve, and there are those that reflect the depths to which people can lower themselves. Know that just as there are bad people who rob banks and mug people in the real world, there are bad people on the Web. Some of these people create traps to prey on unsuspecting surfers.

Depending on your level of paranoia, you might consider all unknown Web sites as risky locations. A good strategy might be to leave Java off by default and turn it on only when you make a conscious decision to trust a site. Many business sites require that their employees use Java this way. This strategy is easy to implement. We discussed how to disable and enable Java on two popular browsers in Chapter 4, "Malicious Applets: Avoiding a Common Nuisance."

This guideline takes on more weight as the world rushes into electronic commerce. If your PC has data on it that help you transact business over the Net (such as trading stocks) then you need to be concerned about computer security. The addition of money (virtual or not) to the Net changes the stakes significantly.

Learn as Much as You Can about Java Security

By reading this book, you are off to a good start. Keep in mind, however, that Java security is a fast-moving field. Since Java's introduction in 1996, the security landscape has changed dramatically:

  • Tens of millions more people are connected to the Internet.
  • Java has undergone two major releases.
  • The security model has evolved to include signed applets.
There is no reason to believe that Java's evolution will slow. In fact, Java's quick move to maturity is essential to its long-term viability as a language.

One way to keep abreast of Java security happenings is to sign up for notification of breaking Java security news. On this book's companion Web site at, you can submit a form to be added to our notification mailing list. Note that this list will not be sold, rented, or otherwise shared with anyone other than the authors. We promise. We hate spam as much as anyone!

You should also keep tabs on the Java Security Hotlist (see Appendix B, "The Java Security Hotlist," and

Know Your Java Environment

Another piece of common-sense advice is to know about the Java tools that you are using. Know how Java works (this book should help). Now that you know how Java treats signed classes with privilege, you know how important it is to consider carefully what your security policy looks like and who created it. Also be aware that early versions of Java (including JDK 1.1) allow built-in code full power to do anything.

Before Java 2, built-in classes were allowed to bypass all security verification checks. If you are using a browser that does not yet support Java 2, never put Java classes (or .jar archives of classes) in your CLASSPATH unless you fully trust the vendor that distributed them. Also be aware that any subdirectories under the directories in your CLASSPATH may be searched for a class as well. Know who built your Java libraries and tools.

Similarly, do not install or otherwise change your Java security policy under the influence of a vendor or other mobile code distributor. A potential social engineering attack against a site running Java 2 could involve convincing a user to redefine security policy in order to run some cool Java code. If you must change policy, think long and hard about why and about who you may be trusting.

Be aware of what Java version you are using. Several companies have licensed the right to produce Java development environments. Some probably do a better job with security than others. If the Java VM is buggy, then Java security is compromised. By using a particular vendor's version of Java, you are trusting the security of your machine to them.

This is actually a general lesson that applies to many technologies. Browser plugins should be subject to similar scrutiny. So, too, should any executable binaries loaded from the Internet.

Finally, find out who controls your browser's Java security policy. Some corporate users may be surprised to learn that they are not in control of their surfing security policy. Starting with version 4, both Netscape Navigator and Microsoft Internet Explorer allow a system administrator to set security policy and lock it in so that it cannot be overridden by users. Some sites attempt to block Java and other mobile code traffic at the firewall (although see Chapter 6, "Securing Java: Improvements, Solutions, and Snake Oil"). If you do control your own policy, make sure you set up a policy that is sound and coherent. Be aware that setting up a security policy is nontrivial and often leads to subtle errors.

Use Up-to-Date Browsers with the Latest Security Updates

This guideline may be a bit counterintuitive, but you should always use the latest version of your favorite browser-even if it is a beta version. All of the security holes discussed in Chapter 5, "Attack Applets: Exploiting Holes in the Security Model," have been fixed in the very latest versions of Netscape and Internet Explorer. Be aware that no new versions of the early releases have been updated to fix bugs. This implies that the beta versions are more secure. Of course, beta versions may also have new bugs of their own.

Recall that although the Princeton Class Loader attack has been fixed for most versions of Netscape (see Applets Running Wild in Chapter 5), the problem persists in version 2.0. The same thing goes for the Jumping-the-Firewall attack. Counting on an old version of a browser for your security is probably not a good idea.

Use the next guideline to help determine which version of a browser you need to have. Then get it.

Keep a Lookout for Security Alerts

Every once in a while, check the latest security information on Java. This book's companion Web site ( is quite current, but you should also keep an eye on the Sun Microsystems official Java Security FAQ ( Also, have someone in your organization (or someone in your group of friends) subscribe to the CERT Alert list (

If the CERT Coordination Center finds a security hole either particularly egregious or particularly popular among crackers, they will warn the community at large. To date, CERT has issued two security alerts about Java. Both were related to attacks found by the Princeton team. The alerts were reprinted in Appendix B of Java Security: Hostile Applets, Holes, & Antidotes (the first edition of this book), where you will also find information about signing up for online delivery of CERT Alerts.

The CERT Alerts have the advantage of telling you the status of any security attacks and how to avoid them. For Java, this includes information about which browser versions are susceptible to a particular attack and which versions have been patched.

More Drastic Measures

There are, of course, a couple of drastic measures that can be applied to lessen Java security risks. These both involve not using Java. These drastic alternatives are not called for unless your information is ultra-critical. If you determine that the risks described are simply too great for you to bear, you can implement these strategies.

Stopping Java at the Firewall

Many firewall vendors claim to have added the capability of stopping Java applets at the gate by using special firewall products. Some firewalls block Java applets by parsing a Web page's HTML code as it arrives. This action is typically performed by the HTTP proxy. HTML-parsing capability makes a firewall capable of blocking any HTML-related tag. Thus, the relevant proxy can cut out Java (by looking for the <APPLET> tag), JavaScript, and even old HTML 2.0 tags that are deemed disallowed during setup. This strategy is useful only for HTML coming in through the proxy via HTTP. That means that applets coming into the system in other ways (for example, through SSL or via ftp) can still get through. Another solution to the same problem might be to try to stop all files with a .class extension at the gate. Still another would be to scan all incoming binaries for the magic number each applet is required to have. The end result is the same: No applets are allowed past the firewall. Research results show that stopping mobile code is much more difficult than it may seem at first glance. An excellent technical paper entitled Blocking Java Applets at the Firewall by David Martin (Boston University), S. Rajagopalan (Bell-core), and Avi Rubin (ATT Research) can be downloaded from (or see the Java Security Hotlist). Stopping all applets at the firewall is a radical solution that gives up all the good things that Java has to offer. It may be a viable alternative for machines that require limited Web access but are considered too important to expose to any risk beyond that. Unfortunately, this strategy resembles throwing the baby out with the bath water.

Hiding Under the Bed

Believe it or not, there are strategies even more paranoid than blocking applets at the firewall. Some sites may have such sensitive information that they decide they can't afford to take any risks at all. These sites protect themselves by not even connecting to the Internet in the first place. Java risk is thoroughly countered by this strategy, but all of the benefits that come with being connected to the Internet are given up in return. Java's power and flexibility may still find room on such a company's intranet, but there will certainly be fewer uses for Java.

Guidelines Are Never Perfect

The guidelines included in this chapter can help you develop more secure code and use Java more securely, but in the end, they can't guarantee anything about security. Following the two sets of guidelines is probably a good idea, but risks will always remain, no matter how vigilant you are. Plan accordingly. If you are doing business on the Net, be particularly careful. The stakes change significantly when it comes to electronic commerce. An appropriate introduction to the security dangers inherent in e-commerce is Anup Ghosh's book, E-Commerce Security [Ghosh, 1998]. Whatever you do, pay close attention to the tradeoffs between functionality and risk. We make security and safety tradeoffs every day when we leave the house, and often they are very appropriate. Making these decisions is more reasonable when you know about potential pitfalls.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)