Java and ActiveX are two systems that let people attach computer programs to Web pages. People like these systems because they allow Web pages to be much more dynamic and interactive than they could be otherwise.
However, Java and ActiveX do introduce some security risk, because they can cause potentially hostile programs to be automatically downloaded and run on your computer, just because you visited some Web page. The downloaded program could try to access or damage the data on your machine, for example to insert a virus. Both Java and ActiveX take measures to protect your from this risk.
There has been a lot of public debate over which system offers better security. This page gives our opinion on this debate. Java and ActiveX take fundamentally different approaches to security. We will concentrate on comparing the approaches, rather than critiquing the details of the two systems. After all, details can be fixed.
Who are the players?
Java was developed by JavaSoft, a division of Sun Microsystems. Java is supported by both of the major browsers, Netscape Navigator and Microsoft Internet Explorer.
ActiveX was developed by Microsoft. It is supported in Microsoft’s Internet Explorer, and an ActiveX plug-in is available for Netscape Navigator.
The most intense public debate about security has been between JavaSoft and Microsoft. Each company has accused the other of being careless about security, and some misleading charges have been made.
How does security work in ActiveX?
ActiveX security relies entirely on human judgement. ActiveX programs come with digital signatures from the author of the program and anybody else who chooses to endorse the program.
Think of a digital signature as being like a person’s signature on paper. Your browser can look at a digital signature and see whether it is genuine, so you can know for sure who signed a program. (That’s the theory, at least. Things don’t always work out so neatly in practice.)
Once your browser has verified the signatures, it tells you who signed the program and asks you whether or not to run it. You have two choices: either accept the program and let it do whatever it wants on your machine, or reject it completely.
ActiveX security relies on you to make correct decisions about which programs to accept. If you accept a malicious program, you are in big trouble.
How does security work in Java?
Java security relies entirely on software technology. Java accepts all downloaded programs and runs them within a security “sandbox”. Think of the sandbox as a security fence that surrounds the program and keeps it away from your private data. As long as there are no holes in the fence, you are safe.
Java security relies on the software implementing the sandbox to work correctly.
How can ActiveX security break down?
The main danger in ActiveX is that you will make the wrong decision about whether to accept a program. One way this can happen is that some person you trust turns out not to deserve that trust.
The most dangerous situation, though, is when the program is signed by someone you don’t know anything about. You’d really like to see what this program does, but if you reject it you won’t be able to see anything. So you rationalize: the odds that this particular program is hostile are very small, so why not go ahead and accept it? After all, you accepted three programs yesterday and nothing went wrong. It’s just human nature to accept the program.
Even if the risk of accepting one program is low, the risk adds up when you repeatedly accept programs. And when you do get the one bad program, there is no limit on how much damage it can do.
The only way to avoid this scenario is to refuse all programs, no matter how fun or interesting they sound, except programs that come from a few people you know well. Who has the self-discipline to do that?
How can Java security break down?
The main danger in Java comes from the complexity of the software that implements the sandbox. Common sense says that complicated technology is more likely to break down than simple technology. Java is pretty complicated, and several breakdowns have happened in the past.
If you’re the average person, you don’t have the time or the desire to examine Java and look for implementation errors. So you have to hope the implementers did everything right. They’re smart and experienced and motivated, but that doesn’t make them infallible.
When Java security does break down, the potential consequences are just as bad as those of an ActiveX problem: a hostile program can come to your machine and access your data at will.
What about “signed applets” in Java?
One problem with the original version of Java is that the “sandbox” can be too restrictive. For example, Java programs are not allowed to access files, so there’s no way to write a text editor. (What good is editing if you can’t save your work?)
Java-enabled products are now starting to use digital signatures to work around this problem. The idea is like ActiveX: programs are digitally signed and you can decide, based on the signature, to give a program more power than it would otherwise have. This lets you run a text editor program if you decide that you trust its author.
The downside of this scheme is that it introduces some of the ActiveX problems. If you make the wrong decision about who to trust, you could be very sorry. There’s no known way to get around this dilemma. Some kinds of programs must be given power in order to be useful, and there’s no ironclad guarantee that those programs will be well-behaved.
Still, Java with signed applets does offer some advantages over ActiveX. You can put only partial trust in a program, while ActiveX requires either full trust or no trust at all. And a Java-enabled browser could keep a record of which dangerous operations are carried out by each trusted program, so it would be easier to reconstruct what happened if anything went wrong. (Current browsers don’t do this record-keeping, but we wish they would.) Finally, Java offers better protection against accidental damage caused by buggy programs.
What about plug-ins?
Plug-ins are a method for adding code to your browser. Plug-ins have the same security model as ActiveX: when you download a plug-in, you are trusting it to be harmless. All of the warnings about ActiveX programs apply to plug-ins too.
Can I be hurt by a “good” plug-in or ActiveX program?
Unfortunately, yes. This depends entirely on what the plug-in or program does. Many plug-ins such as Macromedia’s Shockwave or Sun’s Safe-Tcl are actually completely general programming systems, just like Java. By accepting a plug-in like this, you’re trusting that the plug-in program has no security-relevant bugs. As we have seen with Java, systems that are meant to be secure often have bugs that lead to security problems.
With ActiveX, this problem is made worse if you click the box which accepts all programs signed by the same person (for example, if you accept anything signed by Microsoft). While one Microsoft program may be secure, another one may have a security-relevant bug.
This problem even applies to code written by your own company for internal use. Once the plug-in or program is installed in your browser, an external attacker (who knew about the program) could write a Web page which used your internal program bug passed it funny data which corrupted the program and took over your machine.
If you’re feeling paranoid, the only plug-ins you should allow are those with less than general purpose functionality. A plug-in which handles a new image, video, or audio format is less likely to be exploitable than a plug-in for a completely general animation system.
This sounds pretty scary. How worried should I be?
The good news is that there have been few incidents of people being damaged by hostile Java or ActiveX programs. The reason is simply that the people with the skills to create malicious programs have chosen not to do so.
For most people, continuing to use Java and ActiveX is the right choice. If you are informed about the risks, you can make a rational decision to accept some danger in exchange for the benefits of using Java and ActiveX.
How can I lower my risk?
There are several things you can do.
Think very carefully before accepting a digitally signed program. How competent and trustworthy is the signer?
Use up-to-date browser versions, and install the security patches offered by your browser vendor.
Never surf the Web on a computer that contains highly sensitive information like medical records.
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun’s appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client’s access control list, then applets cannot access the file in any way. Specifically, applets cannot
- check for the existence of the file
- read the file
- write the file
- rename the file
- create a directory on the client file system
- list the files in this file (as if it were a directory)
- check the file’s type
- check the timestamp when the file was last modified
- check the file’s size
Java Applets, one of the GUI enrich feature of Java supports many functionality. Although Java Applets are restricted to some boundaries. It is prevented from doing some functions which are described here.
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.