The great benefit of the Java programming language is that applications written with it can run on any platform that has a Java Virtual Machine (JVM). And there are a lot of them: PCs, Macs, UNIX systems, and even some tablets and phones support Java applications and applets. In addition to the “write once, run on many” convenience, another major Java benefit are the modern security-enhancing features that promote safe coding.
Since 1996 the Java language and platform have seen increasing popularity, largely because they were created for server applications disseminating data over the web. Many enterprise level applications — financial software, medical records systems, document management and even municipal records software systems — are written in Java.
Java applets take advantage of the benefits of Java, allowing them to run indiscriminately on PCs, Macs, and even Linux clients without an installation process. This simplifies the efforts of end users and IT departments that might otherwise have to install these applications. Likewise, applets can be updated easily, securely and transparently. Despite all of these benefits, Java applets have recently garnered some negative attention for security vulnerabilities. To an extent, this is the price of success. Successful solutions and products become targets. And given that no software is perfect, flaws can be found and exploited by motivated hackers.
This means that these solutions have to keep evolving. And that is exactly what is currently going on with Java. New updates of the Oracle JVM now require greater levels of security controls. One recent addition is a requirement that all applets must be digitally signed to ensure they haven’t been modified. Another addition to the latest version (JVM 1.7 U45—automatically installed for most users) now forces users, in many instances, to answer whether they want to run the applet that has been downloaded. Of course, it’s always prudent for a user to recognize what they’re downloading and running, but it can be frustrating and time-consuming for users to deal with this message multiple times.
There are several ways to deal with these changes and prepare for future ones, as well.
- One solution is to have users stay at the older JVM version (1.7 U21) where they won’t be prompted with this message. Of course, this means you are ultimately delaying the inevitable and not taking advantage of the latest JVM updates. On top of all of this, controlling your users’ environments may not even be a feasible option.
- Another potential solution that would allow users to avoid this message is to hardcode the originating website’s domain name into the applet. For example, an applet from Snowbound would have “www.snowbound.com” embedded in its code, meaning it could then only be run from that web server. This greatly increases applet security because it ensures the applet is coming from the correct website. However, in this case, you would still need to run the Snowbound applet as is, without modifications.
- A third solution, should you need to modify the domain name or other items, is to take apart the applet jar file and modify the configuration information, including the domain name. This would allow you to repackage it and sign it with your security certificate.
So what should you do with your Java applets?
I recommend taking advantage of the latest security improvement. Hardcode your domain name into your applet. If you bought your applet from a vendor like Snowbound, have them hardcode it and digitally sign it for you. If it’s your applet, hardcode it with your domain name and then sign it with your certificate so that no one can modify it. If you’re using Snowbound’s Java tools to write your applet and have questions, contact us.
And if there is one critical takeaway from all of this: make sure you are keeping abreast of the latest security developments.
Questions or Suggestions?