The Java programming language and runtime system were designed with security in mind. For example, pointer manipulation is implicit and hidden from the programmer, and any attempt to reference a null pointer results in an exception being thrown. Similarly, an exception results from any attempt to access an array or a string outside of its bounds. Java is a strongly typed language, and all implicit type conversions are well defined and platform independent, as are the arithmetic types and conversions. The Java Virtual Machine (JVM) has a built-in bytecode verifier to ensure that the bytecode being run conforms to the Java™ Language Specification: Java SE 7 Edition (JLS) so that all the checks defined in the language are in place and cannot be circumvented.
The Java class loader mechanism identifies classes as they are loaded into the JVM and can distinguish between trusted system classes and other classes that may not be trusted. Classes from external sources can be given privileges by digitally signing them; these digital signatures can also be examined by the class loader, and contribute to the class’s identification. Java also provides an extensible fine-grained security mechanism that enables the programmer to control access to resources such as system information, files, sockets, and any other security-sensitive resources that the programmer wishes to use. This security mechanism can require that a runtime security manager be in place to enforce a security policy. A security manager and its security policy are usually specified by command-line arguments, but they may be installed programmatically, provided that such an action is not already disallowed by an existing security policy. Privileges to access resources may be extended to nonsystem Java classes by relying on the identification provided by the class loader mechanism.
Enterprise Java applications are susceptible to attacks because they accept untrusted input and interact with complex subsystems. Injection attacks (such as cross-site scripting [XSS], XPath, and LDAP injection) are possible when the components susceptible to these attacks are used in the application. An effective mitigation strategy is to whitelist input and encode or escape output before it is processed for rendering.
This chapter contains guidelines that are concerned specifically with ensuring the security of Java-based applications. Guidelines dealing with the following security nuances are articulated:
- Dealing with sensitive data
- Avoiding common injection attacks
- Language features that can be misused to compromise security
- Details of Java’s fine-grained security mechanism
-
SEC51-J. Minimize privileged code (SEI CERT Oracle Coding Standard for Java)
-
MSC62-J. Store passwords using a hash function (SEI CERT Oracle Coding Standard for Java)
-
-
-
IDS54-J. Prevent LDAP injection (SEI CERT Oracle Coding Standard for Java)
-
IDS53-J. Prevent XPath Injection (SEI CERT Oracle Coding Standard for Java)
-
IDS51-J. Properly encode or escape output (SEI CERT Oracle Coding Standard for Java)
-
IDS52-J. Prevent code injection (SEI CERT Oracle Coding Standard for Java)
-
OBJ56-J. Provide sensitive mutable classes with unmodifiable wrappers (SEI CERT Oracle Coding Standard for Java)
-
MSC59-J. Limit the lifetime of sensitive data (SEI CERT Oracle Coding Standard for Java)
-
SEC53-J. Define custom security permissions for fine-grained security (SEI CERT Oracle Coding Standard for Java)
-
SEC50-J. Avoid granting excess privileges (SEI CERT Oracle Coding Standard for Java)
-
MET56-J. Do not use Object.equals() to compare cryptographic keys (SEI CERT Oracle Coding Standard for Java)
-
SEC55-J. Ensure that security-sensitive methods are called with validated arguments (SEI CERT Oracle Coding Standard for Java)
-
SEC57-J. Do not let untrusted code misuse privileges of callback methods (SEI CERT Oracle Coding Standard for Java)
-
FIO52-J. Do not store unencrypted sensitive information on the client side (SEI CERT Oracle Coding Standard for Java)
-
OBJ57-J. Do not rely on methods that can be overridden by untrusted code (SEI CERT Oracle Coding Standard for Java)
-
IDS56-J. Prevent arbitrary file upload (SEI CERT Oracle Coding Standard for Java)
-
MSC63-J. Ensure that SecureRandom is properly seeded (SEI CERT Oracle Coding Standard for Java)
-
-
SEC54-J. Create a secure sandbox using a security manager (SEI CERT Oracle Coding Standard for Java)