|
The following guidelines provide steps you can take to reduce the vulnerability of the Rich Internet Applications (RIAs) that you provide to users.
Follow the recommendations in the Secure Coding Guidelines for the Java Programming Language. Section 4, "Accessibility and Extensibility" describes how to limit accessibility to classes and packages, which reduces the vulnerability of your code.
JavaScript code is considered insecure and is restricted to the security sandbox by default. Minimize interactions between your RIA and JavaScript code. Use the AccessController.doPrivileged block with care because it allows access from any HTML page or JavaScript code.
Make sure that your RIA runs on the latest, secure version of the JRE. The Java platform supports the ability for RIAs to specify the Java version that is needed to run the RIA, however, requiring users to maintain more than one version of the JRE, especially older, insecure versions, is a security risk for the user.
One of the benefits of RIAs is that updated versions of the RIA are automatically download to a user's system. Test your RIA against each update of the JRE and make sure that it works. If changes are needed, update your RIA on the server so that users can install the latest JRE and still run the RIA.
Add attributes to the JAR file manifest that describe the properties of the RIA. Values in the JNLP file or the applet tag are compared to values in the manifest to verify that the correct code is run.
Request sandbox permissions when your RIA does not require access beyond the security sandbox. The Java sandbox provides additional protections for users, and users might not run a privileged application if they do not understand why it requests unrestricted access to their system.
See Enhancing the Security of the JAR File for information on the manifest attributes that are available.
If your RIA needs to access non-secure system properties or JVM arguments, use a signed JNLP. A signed JNLP file is a JNLP file named APPLICATION.JNLP that is included in the META_INF directory of the JAR file before the JAR file is signed. The external JNLP file used to start the RIA must match the internal JNLP file in the JAR file or the RIA will not be run. If some variation between the external and internal JNLP files is required, use JNLP templates. See Signing JAR Files with a JNLP Template in the Java RIA Development and Deployment Guide for information.
To access non-secure system properties or JVM arguments, include the property or argument in the JNLP file as described in Setting Trusted Arguments and Secure Properties.
Obtain a code signing certificate from a trusted certificate authority and use it to sign the JAR files for your RIA. Deploy to users only RIAs that are signed with a valid certificate.
When you sign your JAR file, also time stamp the signature. Time stamping verifies that the certificate was valid at the time that the JAR was signed, so the RIA is not automatically blocked when the certificate expires. See Signing JAR Files for information on signing and time stamping.
Self-signed and unsigned RIAs are considered unsafe and might not be allowed to run, depending on the setting of the security level in the Java Control Panel and the version of the available JRE. Deploying self-signed or unsigned RIAs to users is not recommended, however, self-signing can be useful for testing purposes. To test using your self-signed RIA, you can import the self-signed certificate into the trusted keystore.
Use the HTTPS protocol for the web server from which users get your RIA. The HTTPS protocol is encrypted and validated by the server, making it more difficult for anyone to tamper with your RIA.
Local RIAs are not intended for use in production. To ensure that users run the code that you intend for them to run, host your RIA on an application server.
For testing, use a local web server. Local RIAs can be run if the Security Level in the Java Control Panel is set to Medium, however, the medium security level is insecure and is not recommended.
|
