BUY IT!
Securing Java

Previous Page
Previous Page
Java Security Guidelines: Developing and Using Java More Securely
CHAPTER SECTIONS: 1 / 2 / 3

Section 2 -- Guidelines for Java Users

Next Page
Next Page

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 www.sun.com 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 www.rstcorp.com/java-security.html, 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 www.rstcorp.com/javasecurity/links.html).


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 (www.securingjava.com) 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 (Bellcore), and Avi Rubin (ATT Research) can be downloaded from www.cs.bu.edu/techreports/96-026-java-firewalls.ps.Z (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.

Previous Page
Previous Page


Search Help
Next Page
Next Page


Menu Map -- Text links below

Chapter... Preface -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 -- 8 -- 9 -- A -- B -- C -- Refs
Front -- Contents -- Help

Copyright ©1999 Gary McGraw and Edward Felten.
All rights reserved.
Published by John Wiley & Sons, Inc.