Java has been the way for developers to write-once, run-anywhere applications. Java was incredibly promising when it emerged on the scene in the mid-90s. It was the ideal abstraction layer - developers write code and any device with a platform-specific JRE (Java Runtime Environment) would be able to execute the app. The leverage was unprecedented, and now, with a reported 10 million users, Java might be the most popular language for client-server web apps.
Willie Sutton's words about robbing banks "because that's where the money is" definitely applies to Java. Java has become a primary target for web-based exploits - not only due to its popularity, but also due to its inherent design.
While Java developers can write once, execution of the code requires the JRE browser plug-in. This plug-in provides all the executables and files that allow the app to run. By design, Java is built to bridge the gap between web-delivered code running in the browser and system resources on the user’s machine. Through the JRE, a Java app could escape the local browser sandbox and access the file system, communication ports, and make native OS calls. This design makes Java an ideal target.
Attempts to solve the problem
To minimize risk, vendors in various positions within the Java ecosystem have delivered localized pseudo-solutions. Some platforms remove Java from their distributions. Others deprecate support for prior versions and force updates to the latest release. Either of these tactics can break legacy apps. Security management agents trap Java calls and present mind-numbing warnings. IT labors to keep Java versions up to date and contained, which isn’t working (as shown here); or maybe IT gets fed up and removes Java altogether, until they realize that some users absolutely must have Java enabled to do their work.
Java needs to be enabled for some popular collaboration, online meeting, payroll, staffing, benefits and healthcare apps - the list goes on. Today, Java is required. And the tension between utility and security has never been greater. Java is a practical reality of doing business on the web, and IT needs a better way to deal with it.
The proper place for Java
If you've been reading this blog, you've followed our progress as we moved the browser to a sandbox in the cloud, built app provisioning workflows, and wrapped it all in a policy framework. Sandboxing Java is the latest request we've heard from our customers, and we see it as a logical extension to our products.
We've looked at the landscape from all angles and think we've arrived at a solution that makes everyone happy. We believe we can keep users productive, put IT back in control, and ease the urgency for web app developers to migrate away from Java.
Silo can be configured to run multiple JREs in our sandbox. We enable the latest v6 and v7 releases and store the version requirement of each web app as part of the metadata in our policy database. As users launch a Java-based app, we invoke the appropriate JRE. Users can even run v6 and v7 apps side by side in the same session. The processes are isolated, so there is no app conflict. And since all execution of Java code occurs in our sandbox, the attack surface is diverted away from your environment.
At the end of every session, everything is deleted (even temporary or malicious data that might have been written to the partition). And most importantly, since the sandbox runs in the cloud, no web code ever reaches the user's device (Mac, PC, or iPad). Silo provides complete insulation for the endpoint.
So, go ahead and remove Java from your users’ machines. But give them an Authentic8 account to maintain access to Java-based apps without the fear of exploit. We’ll run Java securely on our infrastructure. We think that puts Java in its proper place. Tell us what you think.