Thursday, March 26, 2015

Changes to applet JAR manifests for Java 7 onwards

Reading through this official page made me realise that it was not being specific about what needs to be done. The changes are being categorised into each Update without summarising what is the latest set of TODOs in order for your applet to be able to run properly. Here's my TL;DR of this page:
  • MANIFEST.MF (required)
    1. Required:
      1. Application-Name: My Applet Name
      2.  Permissions: sand-box/all-permission
    2. Optional:
      1. Codebase: {list of URLs}
      2. Trusted-Only: true (more secure)
      3. Trusted-Library: true (less secure than Trusted-Only)
      4. Application-Library-Allowable-Codebase: {list of URLs}
      5.  Caller-Allowable-Codebase: {list of URLs}
    3. {list of URLs}:
      1. Can be a single asterix as a wildcard '*' for liberal use of the JAR
      2. Can contain a mix of named/IP addresses
      3. Single line, no linebreaks
      4. Example: http://localhost:9090 https://localhost:9443 some-other.internal.url 172.16.0.1 
  • Signing (required)
    • Can be self-signed
    • Should not be expired
    • Within a secure intranet environment, it is possible to establish the following:
      • A self-signed certificate identified as a Root Certificate Authority (Root CA);
      • This certificate is added to all workstations within the network;
      • Generate a separate certificate for this application JAR file;
      • Sign the application certificate using the Root CA (e.g. 1 year expiry);
      •  Of course, you must be acquainted with the risks of being vulnerable to the CA certificate ever being compromised.
  • Workarounds:
    • Exception Site List
      • Add your URLs manually into individual workstation JRE Control Panel
    • Deployment Rule Set
      • Create an XML according to this page;
      • Better granular control over specific JRE versions you want your application to run using;
      • Wrap the XML inside a signed JAR (e.g. using above Root CA);
      • Push JAR into all workstations on startup.
With some luck using the above, you should not need to edit the java.policy where you have to end up exposing AllPermissions unwittingly causing a vulnerability you never intended to have.

No comments:

Post a Comment