lang="en-US" dir="ltr" xml:lang="en-US">

Mixing Signed and Unsigned Code
Ensuring Application and Applet Security

Contents

Overview

Signed Java Web Start applications and applets that contain signed and unsigned components could potentially be unsafe unless the mixed code was intended by the application vendor. As of the Java SE 6 Update 19 release (or later), when a program contains both signed and unsigned components, a warning dialog is raised. The following is an example of the dialog that the user may see:

Screen shot of Mixed Code Warning Dialog

Clicking the More Information... link brings up the following panel:

Screen shot of the More Information Panel

Clicking Yes blocks potentially unsafe components from running, and the program may terminate. If the user clicks the No button, the application or applet continues execution with some added protections.

Raising a warning is the default behavior, but there are options available to manage how this situation is handled.

Note: If any concepts are unclear, such as how to modify a manifest file, or how to sign a jar file, or how to use a deployment configuration file, see For More Information for useful links.

Mixed Code Protection Options for Users

There are two mechanisms for managing how mixed code programs are handled.
Version note: To take advantage of these security enhancements, users need to install the Java SE or Java for Business 6 Update 19 release (or later) and use the new Java Plugin, which is enabled by default. To use an earlier JRE with the new Java Plugin, you need to install the Java for Business 5.0 Update 24 release (or later) or the Java for Business 1.4.2_26 release (or later) in order to enable the mixed code security enhancement for those release families.
Note 1: Mixed code checking for the 1.4.2 release is available only for the Windows platform.
Note 2: For Solaris, the new Java Plugin requires Firefox 3 or later. Netscape 7 and Firefox 2 are not supported.
Note 3: For more information on which platforms are supported by the new plugin, see the Release Notes for the Next-Generation Java Plugin.

Deploying Signed Applications and Applets Securely Without a Mixed Code Warning

This section describes best practices for developers and deployers to protect their applications and applets from being maliciously re-purposed by replacing trusted components with untrusted ones.

Two new JAR manifest attributes are available, as of Java SE 6 Update 19, for deploying signed applications and applets. A warning dialog is not displayed when one of these manifest attributes is included.

Developers and deployers should check their signed Java Web Start applications and applets to determine if they mix signed and unsigned code. If users of these applications and applets may inadvertently download these applications and applets from rogue websites, deploying or re-deploying with one of the following attributes should be considered. Existing signed jars need to be re-signed after adding one of these manifest attributes. Note: source code of the classes and resources are not required for re-signing with the new manifest entries.

Trusted-Only Attribute

For applications and applets that do not require unsigned components, the Trusted-Only attribute should be used. No warning dialog will be displayed and an application or applet that loads a jar file containing this attribute will not load any untrusted classes or resources. This attribute prevents a signed application or applet from being re-purposed with unsigned components. You can specify Trusted-Only: true in the manifest file. For example:

Manifest-Version: 1.0
Trusted-Only: true
Created-By: 1.6.0-internal (Sun Microsystems Inc.)

All classes and resources in the application or applet must be signed and trusted.

Trusted-Library Attribute

For applications and applets that are designed to allow unsigned components, the Trusted-Library attribute should be used. No warning dialog will be displayed and an application or applet may load jar files containing untrusted classes or resources. This attribute prevents signed components in an application or applet from being re-purposed with unsigned components. You can specify Trusted-Library: true in the manifest file. For example:

Manifest-Version: 1.0
Trusted-Library: true
Created-By: 1.6.0-internal (Sun Microsystems Inc.)

All classes and resources in a jar file containing this manifest attribute must be signed and trusted.

In a mixed code application or applet, all signed classes and resources must be included in jar files that contain the Trusted-Library attribute.

All trusted library jars are loaded into a separate dedicated class loader which is unique to the application or applet instance. This new Trusted-Library loader is now the parent of the normal Web Start or applet class loader. For backwards compatibility with the original search order, both loaders cooperate to implement a common class path. Consistent with prior releases, jar files are lazily downloaded and opened as needed to find requested classes and resources.

Code in a jar file that is to be marked with the Trusted-Library manifest attribute may need to be modified slightly if it uses calls that are class loader dependent, such as the single parameter version of Class.forName(), Class.getResource(), and Class.getResourceAsStream(), some variants of java.util.ResourceBundle.getBundle(), and any other methods which operate relative to their immediate caller's defining loader. Changes only need to be made if the requested class or resource might be found in a jar file which is not a Trusted-Library (and is therefore loaded by the normal Web Start or applet class loader).

Code in a Trusted-Library can look up the normal loader by invoking Thread.currentThread().getContextClassLoader(). Note, however, that there are uncommon circumstances in which getContextClassLoader() may return null. For example, this may happen when the garbage collector uses a JRE system thread to invoke the Object.finalize() method of an unreachable instance.

If you need to convert class to Class.getResource() or Class.getResourceAsStream() to their ClassLoader equivalents, remember to adjust the string parameter as described by the documentation for those two methods. If the original resource name began with '/', then it was an absolute name and the leading '/' simply needs to be removed. Otherwise, determine if the class instance which was the target of the getResource call is in a named package. If it is an array you should first determine the underlying component type of the array. Invoke Class.getName() on the class or component type instance. If the class name contains any '.' characters, it is in a named package that will need to be prepended to the original resource name. Determine the package name by removing any characters after, and including, the trailing '.' character. Next, replace any remaining '.' characters with '/' characters. Finally, add a trailing '/' and append the original resource name string. This new string can now be passed to the ClassLoader version of the getResource() or getResourceAsStream() methods.

Generally, care must be taken to ensure that the code in the trusted library is written in a careful and secure manner and is otherwise compatible with being loaded in a separate class loader instance from any remaining jars which are part of the application and are loaded by the normal loader.

Mixed Code FAQ

For More Information

Copyright © 1993, 2011, Oracle and/or its affiliates. All rights reserved.