Java Coding Guidelines focuses on the Java SE 7 Platform environment and includes guidelines that address the issue of secure coding using the Java SE 7 API. The Java Language Specification: Java SE 7 Edition [JLS 2013] prescribes the behavior of the Java programming language and serves as the primary reference for the development of these guidelines.
Traditional languages standards, such as those for C and C++, include undefined, unspecified, and implementation-defined behaviors that can lead
Rationale
| Wiki Markup |
|---|
The CERT Sun Microsystems Secure Coding Standard for Java focuses on the Java 2 SE 6 Platform environment and includes guidelines that address the issue of secure coding using the Java SE 6 API. The Java Language Specification (3rd edition) \[[JLS 05|AA. Java References#JLS 05]\] prescribes the behavior of the Java programming language and serves as the primary reference for the development of this standard. |
Traditional languages such as C and C++ allow unspecified or implementation defined behavior which leads to vulnerabilities when a programmer makes incorrect assumptions about the underlying behavior of an API or language construct. The Java Language Specification, on the other hand, standardizes language requirements where possible, portability of these behaviors. By contrast, the JLS more completely specifies language behaviors because Java is designed to be a cross-platform language. Even then, certain behaviors are left to the discretion of the implementer of the Java Virtual Machine (JVM) or the Java compiler. This standard identifies These guidelines identify such language peculiarities and suggests , suggest solutions to help the implementers address the issues, and let programmers appreciate and understand the limitations of the language and navigate around them.
Focusing only on language issues does not translate to writing reliable and secure software. Design issues in Java APIs sometimes lead to their deprecation. At other times, the APIs or the relevant documentation may be interpreted incorrectly by the programming community. This standard identifies These guidelines identify such problematic APIs and highlights highlight their correct use. Examples of commonly used faulty design patterns and idioms are also included.
The Java language, its core and extension APIs, and the Java Virtual Machine ( JVM ) provide several security features, such as , the security manager and access controller, cryptography, automatic memory management, strong type checking, and byte code bytecode verification. These features provide sufficient security for most applications, but their proper use is of paramount importance. This standard highlights These guidelines highlight the pitfalls and caveats associated with the security architecture and stresses on stress its correct implementation. Adherence to this standard these guidelines safeguards trusted programs from a plethora of exploitable security bugs that can cause denial of service, information leaks, erroneous computations, and privilege escalation.
Included Libraries
Figure 1.1 is a conceptual diagram of Oracle's Java SE products.
A section dedicated to securing the runtime environment helps enforce many of the guidelines. Software that complies with this standard provides its users the ability to define fine grained security policies and safely execute trusted mobile code on an untrusted system.
Included Libraries
Figure 1.1 Java conceptual diagram of Oracle's Java SE products. (From Oracle Java SE Documentation. Copyright © 1995, 2010, Oracle and/or its affiliates. All rights reserved.)
These coding guidelines address security issues primarily This secure coding standard addresses security issues applicable to the lang and util Base Libraries base libraries as well as Other Base Libraries. Among the Integration Libraries, currently, only JDBC is supported. This standard avoids for "other base libraries." They avoid the inclusion of open bugs that have already been marked to be fixed or and those that do not have any security lack negative ramifications. A functional bug is included only included if it is likely that it occurs to occur with high frequency, causes considerable security or reliability concerns, or affects most Java technologies that rely on the core platform. This standard is These guidelines are not limited to security issues specific to the Core core API but also includes include important reliability and security concerns pertaining to the standard extension APIs (javax package).
Issues not Addressed
Demonstrating the full range of security features that Java offers requires studying interaction of code with other components and frameworks. Occasionally, the coding guidelines use examples from popular web and application frameworks such as Spring and Struts and technologies such as Java Server Pages (JSP) to highlight a security vulnerability that cannot be examined in isolation. Only when the standard API provides no option to mitigate a vulnerability are third-party libraries and solutions suggested.
Issues Not Addressed
A number of issues are There are a number of issues not addressed by this secure coding standard.
Content
These coding guidelines apply broadly to all platforms; concerns specific to only one Java-based platform are beyond the scope of these guidelines. For example, guidelines that are applicable to Android, Java Micro Edition (ME), or Java Enterprise Edition (EE) alone and not to Java Standard Edition (SE) are typically excluded. In Java SE, APIs that deal with the user interface (user interface toolkits) or the web interface for providing features such as sound, graphical rendering, user account access control, session management, authentication, and authorization are beyond the scope of these guidelines. Nevertheless, the guidelines discuss networked Java systems in light of the risks associated with improper input validation and injection flaws and suggest appropriate mitigation strategies. These guidelines assume that the functional specification of the product correctly identifies and prevents higher-level design and architectural vulnerabilities.
Coding Style
Coding style issues are subjective, and ; it has proven impossible to develop a consensus on appropriate style guidelines. Consequently, the CERT Sun Microsystems Secure Coding standard for Java does not require Java™ Coding Guidelines generally avoids requiring enforcement of any particular coding style to be enforced but only . Instead, we suggest that the user defines define style guidelines and apply these those guidelines consistently. The easiest way to consistently apply a coding style is with the use of a code formatting tool. Many interactive integrated development environments (IDEs) provide such capabilities.
Tools
As Many of these guidelines are not amenable to automatic detection or correction. It some cases, tool vendors may choose to implement checkers to identify violations of these guidelines. As a federally funded research and development center (FFRDC), the Software Engineering Institute (SEI) is not in a position to recommend particular vendors or tools to enforce the restrictions adopted. The user of this document is free to choose tools, and vendors are encouraged to provide tools to enforce the rulesfor this purpose.
Controversial
...
Guidelines
In general, the CERT secure coding standards try The CERT Oracle Java Coding Guidelines tries to avoid the inclusion of controversial rules guidelines that lack a broad consensus.
...