Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial DirectorUnlike C++, Java is designed to provide several inherent security features from ground-up and at all levels from the Java language constructs to the Java runtime environment and from the class libraries to the complete application. I would suggest you first to take a look at the fundamental Java security features within the Java programming language. These give the programmer the advantage and freedom to write secure code and execute and distribute it over a network. Those key Java language security features are as follows:
With the above core security features at the programming language level, Java promises a secure programming environment advantage over using C++. Having said that, I would also like to highlight a few things that will enhance the security of your Java code.
1. Restrict access to your Java classes, methods and objects by declaring it as private and by enforcing a Java policy defining access control privileges and permissions. The Java classloader adopts a security manager and access controller that enforces the required security policy of an application by performing runtime checks and authorizing access, thereby protecting resources from malicious operations.
2. Always sign your code so that it allows identification the signer of the code and has its integrity guaranteed by a certificate authority (CA) -- and additionally it can be trusted to run with the permissions granted in the policy file. Signing the code helps to identify untrusted malicious code and helps the end user allow downloading and executing applications after verifying the signer's information. To facilitate signed applications, JDK 1.1.x added support for cryptographic algorithms that provide digital signature capabilities. With this support, a Java class could be signed with digital signatures in the Java archive format (JAR file). The JDK runtime will use the trusted public keys to verify the signers of the downloaded applet and then treat it as a trusted local application, granting access to its resources. To support function related to digital signature, that Java platform does provide a set of tools that helps create keys (for testing purposes only), manage keys and certificates, sign JAR files, verify signatures, and support other functions related to key management.
3. The threat of reverse engineering is a well-known security problem in Java applications. By default, the byte code generated by the Java compiler contains much symbolic information, including the actual Java source of the executable and debugging information. Using reverse engineering mechanisms, it is possible to disassemble and decompile the executable Java byte code into actual Java source code. To counter these issues, there are several tools and techniques that protect the source code from prying eyes by making it difficult to apply any reverse engineering mechanisms. The possible ways to prevent reverse engineering of Java executables and to protect the source code are as follows:
- Code authentication: This approach adopts evaluation and verification of executable code for trusted sources, runtime checks, predictable behavior, and output. This ensures that code is not executed from an unauthorized host, not modified to produce any unpredicted output, and not duplicated to act as an original application.
- Encryption and decryption: Using encryption and decryption of executable code in transmission ensures that the code is not accessible or tampered with during its transit. This approach limits portability of the application but works well in scenarios where applications are made available via server-side invocations.
- Code obfuscation: This approach uses a transformation mechanism that changes the program and generates Java code with obscure references. The obfuscated code is understood by compilers but difficult to read by humans. This is the most popular way to prevent the success of reverse engineering capabilities on executable code.
References: Core Security Patterns: Best Practices and Strategies for J2EE(TM), Web Services, and Identity Management (Prentice Hall, 2006)
This was first published in December 2007