Java RIA security checklist

This document was a notice about changes that occurred in Java 7 update 51 (January 2014). All details about requirements now appear in standard Java Rich Internet Applications Guide for Java SE 7 RIAs and Java SE 8 RIAs.

Java 7 update 51 (January 2014) changes the deployment requirements for Applet & Web Start applications with two new requirements: use of the Permissions manifest attribute and valid code signatures. These changes will not affect developers of back-end or client applications; the scope is limited only to Applets & Web Start Applications (RIAs). 

The following checklist is intended to help development teams track work necessary to accommodate user prompts.

Why are distribution changes being made?

The software security industry performs an activity called Threat Modeling that assists in enumerating the attack surface of an application. These distribution changes address two types of threats:

• Code signatures defend against unknown or tampered code by requiring authenticated information about the publisher. This prevents users from running code by unknown or untrusted publishers and guards against tampered RIA -- any changes to the RIA’s signed code will break the signature.
• The Permissions manifest addresses the threat of repurposing a legitimate application with increased permissions. By bringing the attribute inside the signed JAR file, an attacker cannot copy and redeploy legitimate sandbox applications as all-permissions and act on vulnerabilities within the RIA’s custom code.

Code signatures, along with timestamps, are also an industry best practice in securing the software supply chain. SSL certificates, used by HTTPS, address the communication channel – i.e. data ‘in motion.’ Code signing certificates, on the other hand, address the contents of data ‘at rest.’ Code signing certificates provide the ability to identify the software publisher on a storage medium and determine that no one has modified the code along the way.

Manifest attributes

Documentation for the above Manifest attributes is available in Jar File Manifest Attributes for Security. The Permissions attribute is the only one that is required. Other attributes of Codebase and Caller-Allowable-Codebase are optional because many ISVs may not know the ultimate destination. If that information is available to the software publisher, use of qualified names is encouraged.

Signing JAR files

Instructions for creating a code-signing certificate are available at the tutorial for Signing Code. Many Certificate Authorities provide instructions for using Java’s keytool commands to create a certificate signing request (CSR) to buy a signing certificate.

Certificates signed by a trusted Certificate Authority are accepted by clients without modification. These are recommended for most development organizations to work across a wide number of computers. Self-signed certificates are an option to known communities, but each computer will need to import the certificate into its trust store.

Code signatures can be verified through either of the following commands:

jarsigner -verify filename.jar

If the output does not say "jar verified" then the following command will provide more detail:

jarsigner -verify -verbose -certs filename.jar

Additional information about code signing can be located at Java Applet & Web Start - Code Signing.

Timestamping during signing

By timestamping your artifact at time of signature, you can extend the lifetime of your signature to match the Timestamp Authority. This is strongly recommended for RIAs that will be in use beyond your own certificate’s expiration date. More information about the role of timestamping is available in the post, Signing code for the long-haul.

Dealing with RIAs that cannot be modified

Although developers are encouraged to update RIAs according to the checklist, there are cases where it is not possible to modify already-deployed RIAs. Examples of this are cases where the RIA has been burned onto unmodifiable firmware, the original publisher is unknown or cannot be reached, or various cases dealing with support agreements.

The primary way for dealing with this is with a Deployment Rule Set.

Deployment Rule Set

Since Java 7 update 40 (September 2013), Deployment Rule Set has allowed a desktop administrator to control the level of client compatibility and default prompts across an organization. More information is available at the Deployment Rule Set documentation or the separate blog post, Introducing Deployment Rule Sets.