Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

Java's early growth was spurred by code downloadable over a network, better know as applets. Applet security has evolved with the growth of Java, and today is a source of frequent confusion due to the variety of Java versions, commercially available browsers, and plug-ins.

This article, the third in the series, will cover the various requirements for securely running Java code downloaded from a network. Although mobile code is not a revolutionary concept, Java and the Internet present some unique challenges to computer security. The evolution of the Java architecture and its impact on core Java security was discussed in Parts 1 and 2. This article takes a different tack: a hands-on approach to tie all the concepts together by deploying a simple applet that writes to the local filesystem.

Java security evolution and concepts: Read the whole series!

At the example applet's core is public-key cryptography, introduced earlier in this series. Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine. We'll also discuss how policy files, which accord permissions and keystore, can be used as a repository for public and private keys. Moreover, we'll highlight the Java 2 SDK security tools and Netscape's signtool, since they enable deployment.

This article traces the evolution of Java security, beginning with application security in the initial release of Java 2 and moving on to the latest version of Java 2, version 1.3. This approach helps introduce the concepts gradually, starting with very simple concepts and culminating in a fairly advanced example.

This series does not intend to provide a comprehensive guide to computer security. Computer security is a multifaceted issue touching several disciplines, departments, and cultures. Investments in technologies should be followed up with investments in personnel training, strict enforcement of policies, and periodic review of the overall security policy.

Note: This article features a running Java applet designed to demonstrate applet security issues. Read below for more details.

Application security

Let's begin our investigation by looking at application security. In Part 2 we saw how Java security has evolved from a sandbox model to a fine-grained security model. We also saw that applications (local code) by default get a free reign and are not subject to the same control as applets (network-downloadable code), which are typically deemed as untrusted. In a change from the past, in Java 2 security applications can be optionally subject to the same level of control as applets.

First, a quick note about, the code used in this article to illustrate the security features in Java 2. This program is a slightly modified version of the applet code provided by Sun, available over the Web to illustrate some of the features of Java 2 security. The program, modified to provide application support, attempts to create and write a file on the local filesystem. Access to a local filesystem is screened by the security manager. We will see throughout this article how this particular operation can be permitted in a secure manner.

  * By default, this raises a security exception as an applet.
  * With JDK 1.2 appletviewer, 
  *  if you configure your system to grant applets signed by "Duke"
  *  and downloaded from the Java Software Website to write a file
  *  to your /tmp directory (or to the file named "C:\tmpfoo" on a 
  *  Windows system), then this applet can run.
  * @version JDK 1.2
  * @author  Marianne Mueller
  * @Modified by Raghavan Srinivas[Rags]
import java.awt.*;
import java.lang.*;
import java.applet.*;
public class writeFile extends Applet {
    String myFile = "/tmp/foo";
    File f = new File(myFile);
    DataOutputStream dos;
  public void init() {
    String osname = System.getProperty("");
    if (osname.indexOf("Windows") != -1) {
      myFile="C:" + File.separator + "tmpfoo";
  public void paint(Graphics g) {
     try {
         dos = new DataOutputStream(new BufferedOutputStream(new FileOutputStream(myFile),128));
       dos.writeBytes("Cats can hypnotize you when you least expect it\n");
       g.drawString("Successfully wrote to the file named " + myFile + " -- go take a look at it!", 10, 10);
     catch (SecurityException e) {
       g.drawString("writeFile: caught security exception", 10, 10);
     catch (IOException ioe) {
          g.drawString("writeFile: caught i/o exception", 10, 10);
    public static void main(String args[]) {
     Frame f = new Frame("writeFile");
     writeFile     writefile = new writeFile();
     f.add("Center", writefile);
     f.setSize(300, 100);;

Running the bytecode generated in a Java 2 Runtime Environment, Standard Edition (JRE) will let the application modify the file on the local filesystem by default, since the default policy does not subject Java 2 applications to a security manager. This policy is justified because applications are typically locally generated code and not downloaded over the network. The following command line produces the window shown in Figure 1, indicating that the file was created and written into.

$ java writeFile
Figure 1. writeFile Application -- no security manager

To subject the code to the Java 2 security manager, invoke the following command line, which should produce the results indicated in Figure 2. Notice that the application generated a security exception caused by an attempt to modify the local filesystem. The explicitly included security manager generated the exception.

$ java writeFile
Figure 2. writeFile Application -- including the security manager

The cases illustrated above represent extreme examples of security policy. In the former case, the application was not subject to any control; in the latter, it was subject to a very rigid control. In most cases it will be necessary to set the policy somewhere in between.

You can accomplish an in-between policy using a policy file. To do so, create a policy file called all.policy in the working directory:

grant {
  permission "<<ALL FILES>>", "write";

Running the same piece of code with the following command line will allow modification of the local filesystem:

$ java writeFile

In this example, the application was subject to the security manager, but the overall policy was governed by the policy file, which allowed all files on the local filesystem to be modified. A stricter policy might have been to allow modification of only the relevant file -- tmpfoo in this case.

I'll cover more details of the policy file, including the syntax of the entries, later in this article. But first, let's look at applet security and contrast it with application security.

Applet security

So far, we've studied application security. As such, most of the security features can be accessed and modified via the command line. Providing an adequately secure and yet somewhat flexible policy in an applet environment proves substantially more challenging. We will start by looking at the deployment of an applet in Appletviewer. We'll look at browser-deployed applets later.

Java code policy is primarily dictated by CodeSource, which comprises two pieces of information: the place where the code originated and the person who signed it.


Create a file called writeFile.html with the following contents:

<title> Java Security Example: Writing Files</title>
<h1> Java Security Example: Writing Files </h1>
<APPLET  CODE = writeFile.class  WIDTH = 500 HEIGHT = 50 >

Running the applet with the following command line would result in the window shown in Figure 3:

$ appletviewer writeFile.html
Figure 3. appletviewer -- applets subject to security manager by default

Notice that -- in contrast to what would happen with an application -- the applet generated an exception since the applet is subject to the security manager by default. The installation can be governed by a customizable policy, if required. Running the following command line:

appletviewer -J"" writeFile.html

would, as you might expect, allow modification of the tmpfoo file, since this was permitted in accordance with the policy file.


Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets. Applet security deployment in browsers is substantially different from what we have seen so far, primarily due to the following reasons:

  • A default lack of trust in code downloaded over the network
  • Insufficient access to the command-line options for running the JVM, since the JVM is hosted in the context of a browser
  • Inadequate support for some of the latest security features in the JVMs bundled with browsers

As for the first problem, to obviate the potential problems resulting from running untrusted code, earlier versions of Java used the sandbox model (see "Sidebar 1: Sandbox Model"). Trust is a largely philosophical or emotional issue, rather than a technical issue; however, technology can help. For example, Java code can be signed using certificates. In this example, the signer implicitly vouches for the code by signing it. The onus is ultimately upon the user running the code to trust the signing entity or not, given that these certificates guarantee that the code was indeed signed by the intended person or organization.

The second problem stems from the lack of access to the options for running the JVM in the browser context. For example, there is no simple way to deploy and use customized policy files as we could in the previous example. Instead, such policies will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily.

The third problem, the lack of support for the latest versions of the JRE in the default JVM with the browser, is solved by using the Java plug-in (see "Sidebar 2: Java Plug-in Primer"). Indeed, an underlying issue is that modification of policy files is not very straightforward. Since applets may be deployed on thousands or even millions of client machines, there might be environments where users might not have a good understanding of security or may not be acquainted with methods for modifying the policy file. The Java plug-in provides a workaround, although it's recommended to use policy files wherever practical and applicable.

Next, we'll look in more detail at applet security involving code-signing examples in a browser environment with a Java plug-in. We will confine the discussion to Java plug-in version 1.3 unless explicitly stated otherwise.

The Java plug-in and security

The Java plug-in supports the standard Java 2 SDK, Standard Edition (J2SE), including the security model. All applets run under the standard applet security manager, which prevents potentially malicious applets from performing dangerous operations, such as reading local files. RSA-signed applets can be deployed using the Java plug-in. Additionally, the Java plug-in attempts to run applets in an identical way in both Netscape Navigator and Internet Explorer by avoiding browser-specific resources. This ensures that an RSA-signed applet will run identically in both browsers with the Java plug-in. The Java plug-in also supports HTTPS, a secure version of HTTP.

In order for a plug-in-enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. Also, earlier versions of the Java plug-in supported code signing using DSA, which is not as widely prevalent as RSA.

A new class loader, in the Java plug-in 1.3, overcomes the limitations mentioned above. It implements support for RSA verification and dynamic trust management.

The Software Development Kit (SDK) tools

The three tools dealing with security, available as part of the Java 2 SDK, are:

  • keytool -- Manages keystores and certificates
  • jarsigner -- Generates and verifies JAR signatures
  • policytool -- Manages policy files via a GUI-based tool

We will look at some of these tools' important options in the sections below. Refer to Resources for more detailed documentation associated with particular tools.

1 2 3 4 Page 1
Page 1 of 4
How to choose a low-code development platform