Secure coding standard for java

Rec. Preface

Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs provides specific advice to Java programmers. The application of these Java coding guidelines will lead to better systems that are more robust and more resistant to attack. These guidelines cover a wide range of products coded in Java for devices such as PCs, game players, mobile phones, home appliances, and automotive electronics.

Developers in any programming language should follow a set of guidelines to control the structure of their programs over and above what is specified by the programming language definition, and this is no less the case in Java.

Java programmers need more help than that provided by the Java Language Specification (JLS) [JLS 2013] to produce reliable and secure Java programs. 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 of all possible input. Inevitably, any nontrivial program will encounter a completely unexpected input or situation, and errors will occur. When such errors occur, it is important that the impact is limited, 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 adopting a defensive style of programming.

Some of these guidelines are stylistic, but they are nonetheless important for readability and maintainability of the code. For Java, Oracle 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™ Coding Guidelines is written by the authors of The 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 (SCALe) [Seacord 2013]. However, there are poor Java coding practices that, despite not warranting inclusion in a secure coding standard for Java, can lead to unreliable or insecure programs. Java Coding Guidelines serves to document and warn against such coding practices.

Although not included in 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 ® 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 ® 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 ® 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 throughout this book are given simply by the number and title of the guideline.

Источник

The CERT Oracle Secure Coding Standard for Java

«In the Java world, security is not viewed as an add-on a feature. It is a pervasive way of thinking. Those who forget to think in a secure mindset end up in trouble. But just because the facilities are there doesn’t mean that security is assured automatically. A set of standard practices has evolved over the years. The Secure(R) Coding(R) Standard for Java(TM) is a compendium of these practices. These are not theoretical research papers or product marketing blurbs. This is all serious, mission-critical, battle-tested, enterprise-scale stuff.»

—James A. Gosling, Father of the Java Programming Language

An essential element of secure coding in the Java programming language is a well-documented and enforceable coding standard. Coding standards encourage programmers to follow a uniform set of rules determined by the requirements of the project and organization, rather than by the programmer’s familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes).

The CERT(R) Oracle(R) Secure Coding Standard for Java(TM) provides rules designed to eliminate insecure coding practices that can lead to exploitable vulnerabilities. Application of the standard’s guidelines will lead to higher-quality systems-robust systems that are more resistant to attack. Such guidelines are required for the wide range of products coded in Java-for devices such as PCs, game players, mobile phones, home appliances, and automotive electronics.

After a high-level introduction to Java application security, seventeen consistently organized chapters detail specific rules for key areas of Java development. For each area, the authors present noncompliant examples and corresponding compliant solutions, show how to assess risk, and offer references for further information. Each rule is prioritized based on the severity of consequences, likelihood of introducing exploitable vulnerabilities, and cost of remediation.

The standard provides secure coding rules for the Java SE 6 Platform including the Java programming language and libraries, and also addresses new features of the Java SE 7 Platform. It describes language behaviors left to the discretion of JVM and compiler implementers, guides developers in the proper use of Java’s APIs and security architecture, and considers security concerns pertaining to standard extension APIs (from the javax package hierarchy).The standard covers security issues applicable to these libraries: lang, util, Collections, Concurrency Utilities, Logging, Management, Reflection, Regular Expressions, Zip, I/O, JMX, JNI, Math, Serialization, and JAXP.

Источник

SEI CERT Oracle Coding Standard for Java

The Java rules and recommendations in this wiki are a work in progress and reflect the current thinking of the secure coding community. Because this is a development website, many pages are incomplete or contain errors. As rules and recommendations mature, they are published in report or book form as official releases. These releases are issued as dictated by the needs and interests of the secure software development community.

Create a sign-in account if you want to comment on existing content. If you wish to be more involved and directly edit content on the site, you still need an account, but you’ll also need to request edit privileges.

Front Matter

Rules

Front Matter

Содержимое с указанными метками не найдено.

Recommendations

There are two books available that cover Java: one for rules and the other for guidelines.

The CERT Oracle Secure Coding Standard for Java provides rules for Java Platform Standard Edition 6 and Java SE 7.

Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs provides guidelines, recommendations, and examples to enable the creation of reliable, robust, fast, maintainable, and secure code.

SCALe offers conformance testing of Java language software systems against the CERT Oracle Secure Coding Standard for Java.

• have questions about the Secure Coding wiki
• have recommendations for standards in development
• want to request privileges to participate in standards development

We acknowledge the contributions of the following folks , and we look forward to seeing your name here as well.

This coding standard consists of rules and recommendations, collectively referred to as guidelines. Rules are meant to provide normative requirements for code, whereas recommendations are meant to provide guidance that, when followed, should improve the safety, reliability, and security of software systems. Learn more about the differences.

Link to guidelines using the Tiny Link under Tools→Link to this Page. (This URL will not change if the name of the guideline changes.)

• To eliminate a section from the lists above, label it section and void.
• To have a section listed as a recommendation, label it section and recommendation.
• To have a section listed as a rule, label it section and rule.

13 Комментариев

Daniel Bögner

I would like to see a downloadable version of the Java Secure Coding Standard. Maybe a zip with HTML files or a all-in-one HTML file could be provided. PDF would also be nice. I am sure I am not the only one who is interested in this.

Robert Seacord (Manager)

PDF versions of The CERT Oracle Secure Coding Standard for Java are available from InformIT at http://www.informit.com/store/cert-oracle-secure-coding-standard-for-java-9780321803955

Stijn de Gouw

Seconded. Confluence provides export facilities «out-of-the-box» ( Space Tools > Content Tools > Export tab), but the export option has been disabled explicitly here. Kind request to the administrators: can you enable this option?

Robert Schiela

We appreciate your feedback. As you imply, we have chosen to explicitly not enable that option at this time, and we currently have no plans to enable the option.

Paul Evans

Hi, We have tried to setup PMD rules to automatically detect non-conformities to these rules. Do you have a list of rules that can be 100 percent detected automatically? For us, there are many rules which create false positives. Also, do you have any particular advice on implementing automated detection? Thanks Paul

Mohsen Vakilian

Paul, We’ve implemented a few automated checkers for CERT rules. See http://keshmesh.cs.illinois.edu/. I’d be happy to learn more about your project? Which rules does your tool support? Are your checkers open source?

Yitzhak Mandelbaum

Hi Paul, No, we do not have any such list. One of the problems is, as you point out, that «detected automatically» is really a relative term, based on tolerance for false positives. However, we are actively investigating this question by attempting to develop (heuristic) checkers for as many rules as possible. Regarding particular advice — some rules have specific textual comments regarding the possibilities for automatic detection which might be useful. If you have questions regarding particular rules, please let us know which ones, and we’d be happy to give you what advice we can regarding automatic detection. I should be upfront with one disclaimer: while all rules are rated with remediation levels, and the definition of the remediation levels involves the potential for automatic checking for rule conformance, you should take those interpretations with a grain of salt. That is, while we stand by the remediation difficulty ratings in the abstract, the specific interpretations (in the introduction) in terms of automatic/manual detection/correction are not always applicable. Rather, it is best to go by what, if anything, about automatic detection is mentioned in the textual discussion of the rule. Cheers

Nelson Abel Barranzuela Iman

Es un excelente libro The.CERT.Oracle.Secure.Coding.Standard.for.Java los felicto , muchas gracias desde Piura-Perú.

Источник