...
Java programmers need more help than that provided by the Java Language Specification (JLS) [JLS 2013] to produce reliable and secure Java programs. There are Java contains language features and APIs that can easily be misused, and guidance is needed to avoid theses pitfalls.
For a program to be reliable, it must work in all situations and in the face all of all possible input. Inevitably, any non-trivial nontrivial program will encounter a completely unexpected input or situation, and errors will occur. When this happens such errors occur, it is important that the impact is limited. This , which is best achieved by localizing the error and dealing with it as soon as possible. Programmers can benefit from the experience of others in anticipating unusual input or programming situations and adopt adopting a defensive style of programming.The Java Programming Language and runtime system were designed with security in mind. 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 machine 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 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 being digitally signed; these digital signatures are also 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 include. This requires that there is a runtime security manager in place which enforces a security policy. A security manager and its security policy are usually specified by command-line arguments, but they may be put in place programmatically provided that such an action is not already disallowed by an existing security policy. Privileges to access resources may be extended to non-system Java classes by relying on the identification provided by the class loader.
Some of these guidelines are stylistic, but even these they are nonetheless important for readability and maintainability of the code. For Java, Oracle has provided provides a set of Code Conventions [Conventions 2009] to help programmers produce a consistent programming style, and these conventions are widely adopted by Java programmers.
The
...
CERT® Oracle® Secure Coding Standard for Java
Java Java™ Coding Guidelines is written by the authors of The CERT® Oracle® CERT® Oracle® Secure Coding Standard for Java [Long 2011]. That coding standard provides a set of rules for secure coding in the Java programming language. The goal of those rules is to eliminate insecure coding practices that can lead to exploitable vulnerabilities. The Secure Coding Standard establishes normative requirements for software systems. These software systems can then be evaluated for conformance to the coding standard, for example, by using the Source Code Analysis Laboratory (SCALEeSCALe) [Seacord 2013]. However, there are poor Java coding practices that, although they do despite not warrant warranting inclusion in a secure coding standard for Java, can lead to unreliable or insecure programs. This book Java Coding Guidelines serves to document and warn against such coding practices.
Although not included in the The CERT® Oracle® The CERT® Oracle® Secure Coding Standard for Java, these guidelines should not be considered less important. Guidelines must be excluded from a coding standard when it is not possible to form a normative requirement. There are many reasons that a normative requirement cannot be formed. Perhaps the most common is that the rule depends on programmer intent. Such rules cannot be automatically enforced unless it is possible for the programmer's intent to be specified, in which case, a rule could require consistency between the code and the specified intent. Forming a normative requirement also requires that a violation of that requirement represent a defect in the code. Guidelines have been excluded from the coding standard (but included in this book) in cases where compliance with the guideline is always a good idea, but violating the guideline does not always result in an error. This distinction is made because a system cannot be cited for nonconformance without a specific defect. Consequently, coding rules must be very narrowly defined. Coding guidelines can often have a more far-reaching impact on security and reliability just because they can be more broadly defined.
Many of the guidelines refer to rules in The CERT® Oracle® CERT® Oracle® Secure Coding Standard for Java. These references are of the form IDS01-J. Normalize strings before validating them, where the first three letters of the reference identify the appropriate chapter of The CERT® Oracle® CERT® Oracle® Secure Coding Standard for Java. For example, IDS refers to Chapter 2, "Input Validation and Data Sanitization (IDS)."
The Secure Coding Standard for Java rules are also available on CERT's secure coding wiki at https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java, where they continue to evolve. The CERT® Oracle® The CERT® Oracle® Secure Coding Standard for Java provides the definition of the rules for conformance testing purposes, but the wiki may contain additional information or insights not included in the book that may help you interpret the meaning of these rules.
Cross references to other guidelines througout throughout this book are given simply given by the number and title of the guideline.
Rec.: Contents and Organization
Rec.: Automatically Generated Code
Rec.: Tool Selection and Validation
...