Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Java security evolution and concepts, Part 3: Applet security

Tackle Java applet security with confidence

By Raghavan N. Srinivas, JavaWorld.com, 12/15/00

  • Print
  • Feedback
.

Page 3 of 6

$ java -Djava.security.manager -Djava.security.policy=all.policy 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.

Appletviewer

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

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


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"-Djava.security.policy=all.policy" writeFile.html


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

Browsers

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.

  • Print
  • Feedback

Resources