Many Web-based applications use the Java programming language to create mobile code objects (applets) that execute on the end user's machine. As a security professional, you need to have an understanding of how this technology functions from a security perspective to ensure that it's properly implemented on your Web server and that you understand the risks and countermeasures when users on your network download mobile code from other sources.
The driving force behind Java is the transfer of the processing burden from the overtaxed Web server to the remote client. This procedure has several security and privacy ramifications. First, it provides users with the confidence that the data they process in a Java applet stays resident on their machine and is not (normally) transferred to the server. On the flip side, however, it requires the server to transfer the actual Java object to the client computer, a risky proposition if the object includes proprietary and/or trade secret information. You certainly wouldn't want to make it easy for a competitor to reverse-engineer your algorithm.
MORE INFORMATION ON JAVA:
Perhaps the most significant mobile code security concern from the client's perspective is the fact that code, potentially from an untrusted source, executes on the local machine. Most often, the client does not inspect the code prior to execution (and wouldn't have the technical qualifications to inspect the code even if technically feasible!). Without appropriate countermeasures, this code could run amuck and misappropriate system resources. Fortunately, the Java 2 Platform includes a comprehensive security architecture that addresses these concerns in a flexible manner.
The new security architecture revolves around the concept of the Java sandbox – a special memory area set aside by the Java Virtual Machine (JVM) for the execution of untrusted code. An illustration of the Java sandbox is shown in the figure below:
Under previous versions of Java, this model was as simple as that. Code was either trusted or untrusted and was executed inside or outside of the sandbox. If code was trusted, it had access to system resources. Untrusted code ran in an extremely limited functionality environment. The new Java model expands on this capability and allows the specification of complex, granular security policies that allow users to assign different trust levels to different Java classes. This flexibility allows a wider range of code execution, but requires attention from administrators to ensure proper implementation.
Java is an extremely powerful language and we're likely to see much more of it in the future. As a security professional, you must take the time to stay on top of these trends and ensure that you understand the evolving Java security environment. For more reading on Java's security functionality, visit the Java Security Web site.
About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.
This tip originally appeared on SearchSecurity.com.
