CERT Oracle Secure Coding Standard for Java, The
Published on 29. September 2011
Book
Paperback/Softback
744 pages
978-0-321-80395-5 (ISBN)
Description
"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 JavaTM 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 JavaTM 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.
-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 JavaTM 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.
More details
Series
Language
English
Place of publication
New Jersey
United States
Publishing group
Pearson Education (US)
Target group
Professional and scholarly
Dimensions
Height: 230 mm
Width: 179 mm
Thickness: 38 mm
Weight
1140 gr
ISBN-13
978-0-321-80395-5 (9780321803955)
Copyright in bibliographic data and cover images is held by Nielsen Book Services Limited or by the publishers or by their respective licensors: all rights reserved.
Schweitzer Classification
Other editions
Additional editions
Fred Long | Dhruv Mohindra | Robert Seacord
CERT Oracle Secure Coding Standard for Java, The
E-Book
09/2011
1st Edition
Addison Wesley
€51.49
Available for download
Fred Long | Dhruv Mohindra | Robert C. Seacord
CERT Oracle Secure Coding Standard for Java, The
E-Book
08/2011
1st Edition
Addison Wesley
€35.49
Available for download
Persons
Ve>Fred Long is a senior lecturer and director of learning and teaching in the Department of Computer Science, Aberystwyth University in the United Kingdom. He lectures on formal methods; Java, C++, and C programming paradigms and programming-related security issues. He is chairman of the British Computer Society's Mid-Wales Sub-Branch. Fred has been a Visiting Scientist at the Software Engineering Institute since 1992. Recently, his research has involved the investigation of vulnerabilities in Java.
Dhruv Mohindra is a senior software engineer at Persistent Systems Limited, India, where he develops monitoring software for widely used enterprise servers. He has worked for CERT at the Software Engineering Institute and continues to collaborate to improve the state of security awareness in the programming community.
Dhruv has also worked for Carnegie Mellon University, where he obtained his master of science degree in information security policy and management. He holds an undergraduate degree in computer engineering from Pune University, India, where he researched with Calsoft, Inc., during his academic pursuit.
A writing enthusiast, Dhruv occasionally contributes articles to technology magazines and online resources. He brings forth his experience and learning from developing and securing service oriented applications, server monitoring software, mobile device applications, web-based data miners, and designing user-friendly security interfaces.
Robert C. Seacord is a computer security specialist and writer. He is the author of books on computer security, legacy system modernization, and component-based software engineering.
Robert manages the Secure Coding Initiative at CERT, located in Carnegie Mellon's Software Engineering Institute in Pittsburgh, Pennsylvania. CERT, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure. Robert is an adjunct professor in the Carnegie Mellon University School of Computer Science and in the Information Networking Institute.
Robert started programming professionally for IBM in 1982, working in communications and operating system software, processor development, and software engineering. Robert also has worked at the X Consortium, where he developed and maintained code for the Common Desktop Environment and the X Window System. Robert has a bachelor's degree in computer science from Rensselaer Polytechnic Institute.
Dean F. Sutherland is a senior software security engineer at CERT. Dean received his Ph.D. in software engineering from Carnegie Mellon in 2008. Before his return to academia, he spent 14 years working as a professional software engineer at Tartan, Inc. He spent the last six of those years as a senior member of the technical staff and a technical lead for compiler backend technology. He was the primary active member of the corporate R&D group, was a key instigator of the design and deployment of a new software development process for Tartan, led R&D projects, and provided both technical and project leadership for the 12-person compiler back-end group.
David Svoboda is a software security engineer at CERT. David has been the primary developer on a diverse set of software development projects at Carnegie Mellon since 1991, ranging from hierarchical chip modeling and social organization simulation to automated machine translation (AMT). His KANTOO AMT software, developed in 1996, is still in production use at Caterpillar. He has over 13 years of Java development experience, starting with Java 2, and his Java projects include Tomcat servlets and Eclipse plug-ins. David is also actively involved in several ISO standards groups: the JTC1/SC22/WG14 group for the C programming language and the JTC1/ SC22/WG21 group for C++.
Dhruv Mohindra is a senior software engineer at Persistent Systems Limited, India, where he develops monitoring software for widely used enterprise servers. He has worked for CERT at the Software Engineering Institute and continues to collaborate to improve the state of security awareness in the programming community.
Dhruv has also worked for Carnegie Mellon University, where he obtained his master of science degree in information security policy and management. He holds an undergraduate degree in computer engineering from Pune University, India, where he researched with Calsoft, Inc., during his academic pursuit.
A writing enthusiast, Dhruv occasionally contributes articles to technology magazines and online resources. He brings forth his experience and learning from developing and securing service oriented applications, server monitoring software, mobile device applications, web-based data miners, and designing user-friendly security interfaces.
Robert C. Seacord is a computer security specialist and writer. He is the author of books on computer security, legacy system modernization, and component-based software engineering.
Robert manages the Secure Coding Initiative at CERT, located in Carnegie Mellon's Software Engineering Institute in Pittsburgh, Pennsylvania. CERT, among other security-related activities, regularly analyzes software vulnerability reports and assesses the risk to the Internet and other critical infrastructure. Robert is an adjunct professor in the Carnegie Mellon University School of Computer Science and in the Information Networking Institute.
Robert started programming professionally for IBM in 1982, working in communications and operating system software, processor development, and software engineering. Robert also has worked at the X Consortium, where he developed and maintained code for the Common Desktop Environment and the X Window System. Robert has a bachelor's degree in computer science from Rensselaer Polytechnic Institute.
Dean F. Sutherland is a senior software security engineer at CERT. Dean received his Ph.D. in software engineering from Carnegie Mellon in 2008. Before his return to academia, he spent 14 years working as a professional software engineer at Tartan, Inc. He spent the last six of those years as a senior member of the technical staff and a technical lead for compiler backend technology. He was the primary active member of the corporate R&D group, was a key instigator of the design and deployment of a new software development process for Tartan, led R&D projects, and provided both technical and project leadership for the 12-person compiler back-end group.
David Svoboda is a software security engineer at CERT. David has been the primary developer on a diverse set of software development projects at Carnegie Mellon since 1991, ranging from hierarchical chip modeling and social organization simulation to automated machine translation (AMT). His KANTOO AMT software, developed in 1996, is still in production use at Caterpillar. He has over 13 years of Java development experience, starting with Java 2, and his Java projects include Tomcat servlets and Eclipse plug-ins. David is also actively involved in several ISO standards groups: the JTC1/SC22/WG14 group for the C programming language and the JTC1/ SC22/WG21 group for C++.
Content
Foreword xvii
Preface xix
Acknowledgments xxxi
About the Authors xxxiii
Chapter 1: Introduction 1
Misplaced Trust 2
Injection Attacks 2
Leaking Sensitive Data 4
Leaking Capabilities 6
Denial of Service 7
Serialization 10
Concurrency, Visibility, and Memory 11
Principle of Least Privilege 18
Security Managers 19
Class Loaders 21
Summary 21
Chapter 2: Input Validation and Data Sanitization (IDS) 23
Rules 23
Risk Assessment Summary 24
IDS00-J. Sanitize untrusted data passed across a trust boundary 24
IDS01-J. Normalize strings before validating them 34
IDS02-J. Canonicalize path names before validating them 36
IDS03-J. Do not log unsanitized user input 41
IDS04-J. Limit the size of files passed to ZipInputStream 43
IDS05-J. Use a subset of ASCII for file and path names 46
IDS06-J. Exclude user input from format strings 48
IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method 50
IDS08-J. Sanitize untrusted data passed to a regex 54
IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale 59
IDS10-J. Do not split characters between two data structures 60
IDS11-J. Eliminate noncharacter code points before validation 66
IDS12-J. Perform lossless conversion of String data between differing character encodings 68
IDS13-J. Use compatible encodings on both sides of file or network I/O 71
Chapter 3: Declarations and Initialization (DCL) 75
Rules 75
Risk Assessment Summary 75
DCL00-J. Prevent class initialization cycles 75
DCL01-J. Do not reuse public identifiers from the Java Standard Library 79
DCL02-J. Declare all enhanced for statement loop variables final 81
Chapter 4: Expressions (EXP) 85
Rules 85
Risk Assessment Summary 85
EXP00-J. Do not ignore values returned by methods 86
EXP01-J. Never dereference null pointers 88
EXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays 90
EXP03-J. Do not use the equality operators when comparing values of boxed primitives 91
EXP04-J. Ensure that autoboxed values have the intended type 97
EXP05-J. Do not write more than once to the same variable within an expression 100
EXP06-J. Do not use side-effecting expressions in assertions 103
Chapter 5: Numeric Types and Operations (NUM) 105
Rules 105
Risk Assessment Summary 106
NUM00-J. Detect or prevent integer overflow 106
NUM01-J. Do not perform bitwise and arithmetic operations on the same data 114
NUM02-J. Ensure that division and modulo operations do not result in divide-by-zero errors 119
NUM03-J. Use integer types that can fully represent the possible range of unsigned data 121
NUM04-J. Do not use floating-point numbers if precise computation is required 122
NUM05-J. Do not use denormalized numbers 125
NUM06-J. Use the strictfp modifier for floating-point calculation consistency across platforms 128
NUM07-J. Do not attempt comparisons with NaN 132
NUM08-J. Check floating-point inputs for exceptional values 134
NUM09-J. Do not use floating-point variables as loop counters 136
NUM10-J. Do not construct BigDecimal objects from floating-point literals 138
NUM11-J. Do not compare or inspect the string representation of floating-point values 139
NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data 141
NUM13-J. Avoid loss of precision when converting primitive integers to floating-point 146
Chapter 6: Object Orientation (OBJ) 151
Rules 151
Risk Assessment Summary 152
OBJ00-J. Limit extensibility of classes and methods with invariants to trusted subclasses only 152
OBJ01-J. Declare data members as private and provide accessible wrapper methods 159
OBJ02-J. Preserve dependencies in subclasses when changing superclasses 162
OBJ03-J. Do not mix generic with nongeneric raw types in new code 169
OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code 175
OBJ05-J. Defensively copy private mutable class members before returning their references 180
OBJ06-J. Defensively copy mutable inputs and mutable internal components 185
OBJ07-J. Sensitive classes must not let themselves be copied 189
OBJ08-J. Do not expose private members of an outer class from within a nested class 192
OBJ09-J. Compare classes and not class names 194
OBJ10-J. Do not use public static nonfinal variables 197
OBJ11-J. Be wary of letting constructors throw exceptions 199
Chapter 7: Methods (MET) 209
Rules 209
Risk Assessment Summary 210
MET00-J. Validate method arguments 210
MET01-J. Never use assertions to validate method arguments 213
MET02-J. Do not use deprecated or obsolete classes or methods 215
MET03-J. Methods that perform a security check must be declared private or final 217
MET04-J. Do not increase the accessibility of overridden or hidden methods 218
MET05-J. Ensure that constructors do not call overridable methods 220
MET06-J. Do not invoke overridable methods in clone() 223
MET07-J. Never declare a class method that hides a method declared in a superclass or superinterface 226
MET08-J. Ensure objects that are equated are equatable 229
MET09-J. Classes that define an equals() method must also define a hashCode() method 238
MET10-J. Follow the general contract when implementing the compareTo() method 241
MET11-J. Ensure that keys used in comparison operations are immutable 243
MET12-J. Do not use finalizers 248
Chapter 8: Exceptional Behavior (ERR) 255
Rules 255
Risk Assessment Summary 255
ERR00-J. Do not suppress or ignore checked exceptions 256
ERR01-J. Do not allow exceptions to expose sensitive information 263
ERR02-J. Prevent exceptions while logging data 268
ERR03-J. Restore prior object state on method failure 270
ERR04-J. Do not exit abruptly from a finally block 275
ERR05-J. Do not let checked exceptions escape from a finally block 277
ERR06-J. Do not throw undeclared checked exceptions 280
ERR07-J. Do not throw RuntimeException, Exception, or Throwable 285
ERR08-J. Do not catch NullPointerException or any of its ancestors 288
ERR09-J. Do not allow untrusted code to terminate the JVM 296
Chapter 9: Visibility and Atomicity (VNA) 301
Rules 301
Risk Assessment Summary 301
VNA00-J. Ensure visibility when accessing shared primitive variables 302
VNA01-J. Ensure visibility of shared references to immutable objects 306
VNA02-J. Ensure that compound operations on shared variables are atomic 309
VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic 317
VNA04-J. Ensure that calls to chained methods are atomic 323
VNA05-J. Ensure atomicity when reading and writing 64-bit values 328
Chapter 10: Locking (LCK) 331
Rules 331
Risk Assessment Summary 332
LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code 332
LCK01-J. Do not synchronize on objects that may be reused 339
LCK02-J. Do not synchronize on the class object returned by getClass() 343
LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects 347
LCK04-J. Do not synchronize on a collection view if the backing collection is accessible 348
LCK05-J. Synchronize access to static fields that can be modified by untrusted code 351
LCK06-J. Do not use an instance lock to protect shared static data 352
LCK07-J. Avoid deadlock by requesting and releasing locks in the same order 355
LCK08-J. Ensure actively held locks are released on exceptional conditions 365
LCK09-J. Do not perform operations that can block while holding a lock 370
LCK10-J. Do not use incorrect forms of the double-checked locking idiom 375
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy 381
Chapter 11: Thread APIs (THI) 387
Rules 387
Risk Assessment Summary 387
THI00-J. Do not invoke Thread.run() 388
THI01-J. Do not invoke ThreadGroup methods 390
THI02-J. Notify all waiting threads rather than a single thread 394
THI03-J. Always invoke wait() and await() methods inside a loop 401
THI04-J. Ensure that threads performing blocking operations can be terminated 404
THI05-J. Do not use Thread.stop() to terminate threads 412
Chapter 12: Thread Pools (TPS) 417
Rules 417
Risk Assessment Summary 417
TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts 418
TPS01-J. Do not execute interdependent tasks in a bounded thread pool 421
TPS02-J. Ensure that tasks submitted to a thread pool are interruptible 428
TPS03-J. Ensure that tasks executing in a thread pool do not fail silently 431
TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools 436
Chapter 13: Thread-Safety Miscellaneous (TSM) 441
Rules 441
Risk Assessment Summary 441
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe 442
TSM01-J. Do not let the this reference escape during object construction 445
TSM02-J. Do not use background threads during class initialization 454
TSM03-J. Do not publish partially initialized objects 459
Chapter 14: Input Output (FIO) 467
Rules 467
Risk Assessment Summary 468
FIO00-J. Do not operate on files in shared directories 468
FIO01-J. Create files with appropriate access permissions 478
FIO02-J. Detect and handle file-related errors 481
FIO03-J. Remove temporary files before termination 483
FIO04-J. Close resources when they are no longer needed 487
FIO05-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code 493
FIO06-J. Do not create multiple buffered wrappers on a single InputStream 496
FIO07-J. Do not let external processes block on input and output streams 500
FIO08-J. Use an int to capture the return value of methods that read a character or byte 504
FIO09-J. Do not rely on the write() method to output integers outside the range 0 to 255 507
FIO10-J. Ensure the array is filled when using read() to fill an array 509
FIO11-J. Do not attempt to read raw binary data as character data 511
FIO12-J. Provide methods to read and write little-endian data 513
FIO13-J. Do not log sensitive information outside a trust boundary 516
FIO14-J. Perform proper cleanup at program termination 519
Chapter 15: Serialization (SER) 527
Rules 527
Risk Assessment Summary 528
SER00-J. Maintain serialization compatibility during class evolution 528
SER01-J. Do not deviate from the proper signatures of serialization methods 531
SER02-J. Sign then seal sensitive objects before sending them across a trust boundary 534
SER03-J. Do not serialize unencrypted, sensitive data 541
SER04-J. Do not allow serialization and deserialization to bypass the security manager 546
SER05-J. Do not serialize instances of inner classes 549
SER06-J. Make defensive copies of private mutable components during deserialization 551
SER07-J. Do not use the default serialized form for implementation-defined invariants 553
SER08-J. Minimize privileges before deserializing from a privileged context 558
SER09-J. Do not invoke overridable methods from the readObject() method 562
SER10-J. Avoid memory and resource leaks during serialization 563
SER11-J. Prevent overwriting of externalizable objects 566
Chapter 16: Platform Security (SEC) 569
Rules 569
Risk Assessment Summary 570
SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary 570
SEC01-J. Do not allow tainted variables in privileged blocks 574
SEC02-J. Do not base security checks on untrusted sources 577
SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes 579
SEC04-J. Protect sensitive operations with security manager checks 582
SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields 585
SEC06-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar 592
SEC07-J. Call the superclass's getPermissions() method when writing a custom class loader 597
SEC08-J. Define wrappers around native methods 599
Chapter 17: Runtime Environment (ENV) 603
Rules 603
Risk Assessment Summary 603
ENV00-J. Do not sign code that performs only unprivileged operations 604
ENV01-J. Place all security-sensitive code in a single jar and sign and seal it 606
ENV02-J. Do not trust the values of environment variables 610
ENV03-J. Do not grant dangerous combinations of permissions 613
ENV04-J. Do not disable bytecode verification 617
ENV05-J. Do not deploy an application that can be remotely monitored 618
Chapter 18: Miscellaneous (MSC) 625
Rules 625
Risk Assessment Summary 625
MSC00-J. Use SSLSocket rather than Socket for secure data exchange 626
MSC01-J. Do not use an empty infinite loop 630
MSC02-J. Generate strong random numbers 632
MSC03-J. Never hard code sensitive information 635
MSC04-J. Do not leak memory 638
MSC05-J. Do not exhaust heap space 647
MSC06-J. Do not modify the underlying collection when an iteration is in progress 653
MSC07-J. Prevent multiple instantiations of singleton objects 657
Glossary 669
References 677
Index 693
Preface xix
Acknowledgments xxxi
About the Authors xxxiii
Chapter 1: Introduction 1
Misplaced Trust 2
Injection Attacks 2
Leaking Sensitive Data 4
Leaking Capabilities 6
Denial of Service 7
Serialization 10
Concurrency, Visibility, and Memory 11
Principle of Least Privilege 18
Security Managers 19
Class Loaders 21
Summary 21
Chapter 2: Input Validation and Data Sanitization (IDS) 23
Rules 23
Risk Assessment Summary 24
IDS00-J. Sanitize untrusted data passed across a trust boundary 24
IDS01-J. Normalize strings before validating them 34
IDS02-J. Canonicalize path names before validating them 36
IDS03-J. Do not log unsanitized user input 41
IDS04-J. Limit the size of files passed to ZipInputStream 43
IDS05-J. Use a subset of ASCII for file and path names 46
IDS06-J. Exclude user input from format strings 48
IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method 50
IDS08-J. Sanitize untrusted data passed to a regex 54
IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale 59
IDS10-J. Do not split characters between two data structures 60
IDS11-J. Eliminate noncharacter code points before validation 66
IDS12-J. Perform lossless conversion of String data between differing character encodings 68
IDS13-J. Use compatible encodings on both sides of file or network I/O 71
Chapter 3: Declarations and Initialization (DCL) 75
Rules 75
Risk Assessment Summary 75
DCL00-J. Prevent class initialization cycles 75
DCL01-J. Do not reuse public identifiers from the Java Standard Library 79
DCL02-J. Declare all enhanced for statement loop variables final 81
Chapter 4: Expressions (EXP) 85
Rules 85
Risk Assessment Summary 85
EXP00-J. Do not ignore values returned by methods 86
EXP01-J. Never dereference null pointers 88
EXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays 90
EXP03-J. Do not use the equality operators when comparing values of boxed primitives 91
EXP04-J. Ensure that autoboxed values have the intended type 97
EXP05-J. Do not write more than once to the same variable within an expression 100
EXP06-J. Do not use side-effecting expressions in assertions 103
Chapter 5: Numeric Types and Operations (NUM) 105
Rules 105
Risk Assessment Summary 106
NUM00-J. Detect or prevent integer overflow 106
NUM01-J. Do not perform bitwise and arithmetic operations on the same data 114
NUM02-J. Ensure that division and modulo operations do not result in divide-by-zero errors 119
NUM03-J. Use integer types that can fully represent the possible range of unsigned data 121
NUM04-J. Do not use floating-point numbers if precise computation is required 122
NUM05-J. Do not use denormalized numbers 125
NUM06-J. Use the strictfp modifier for floating-point calculation consistency across platforms 128
NUM07-J. Do not attempt comparisons with NaN 132
NUM08-J. Check floating-point inputs for exceptional values 134
NUM09-J. Do not use floating-point variables as loop counters 136
NUM10-J. Do not construct BigDecimal objects from floating-point literals 138
NUM11-J. Do not compare or inspect the string representation of floating-point values 139
NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data 141
NUM13-J. Avoid loss of precision when converting primitive integers to floating-point 146
Chapter 6: Object Orientation (OBJ) 151
Rules 151
Risk Assessment Summary 152
OBJ00-J. Limit extensibility of classes and methods with invariants to trusted subclasses only 152
OBJ01-J. Declare data members as private and provide accessible wrapper methods 159
OBJ02-J. Preserve dependencies in subclasses when changing superclasses 162
OBJ03-J. Do not mix generic with nongeneric raw types in new code 169
OBJ04-J. Provide mutable classes with copy functionality to safely allow passing instances to untrusted code 175
OBJ05-J. Defensively copy private mutable class members before returning their references 180
OBJ06-J. Defensively copy mutable inputs and mutable internal components 185
OBJ07-J. Sensitive classes must not let themselves be copied 189
OBJ08-J. Do not expose private members of an outer class from within a nested class 192
OBJ09-J. Compare classes and not class names 194
OBJ10-J. Do not use public static nonfinal variables 197
OBJ11-J. Be wary of letting constructors throw exceptions 199
Chapter 7: Methods (MET) 209
Rules 209
Risk Assessment Summary 210
MET00-J. Validate method arguments 210
MET01-J. Never use assertions to validate method arguments 213
MET02-J. Do not use deprecated or obsolete classes or methods 215
MET03-J. Methods that perform a security check must be declared private or final 217
MET04-J. Do not increase the accessibility of overridden or hidden methods 218
MET05-J. Ensure that constructors do not call overridable methods 220
MET06-J. Do not invoke overridable methods in clone() 223
MET07-J. Never declare a class method that hides a method declared in a superclass or superinterface 226
MET08-J. Ensure objects that are equated are equatable 229
MET09-J. Classes that define an equals() method must also define a hashCode() method 238
MET10-J. Follow the general contract when implementing the compareTo() method 241
MET11-J. Ensure that keys used in comparison operations are immutable 243
MET12-J. Do not use finalizers 248
Chapter 8: Exceptional Behavior (ERR) 255
Rules 255
Risk Assessment Summary 255
ERR00-J. Do not suppress or ignore checked exceptions 256
ERR01-J. Do not allow exceptions to expose sensitive information 263
ERR02-J. Prevent exceptions while logging data 268
ERR03-J. Restore prior object state on method failure 270
ERR04-J. Do not exit abruptly from a finally block 275
ERR05-J. Do not let checked exceptions escape from a finally block 277
ERR06-J. Do not throw undeclared checked exceptions 280
ERR07-J. Do not throw RuntimeException, Exception, or Throwable 285
ERR08-J. Do not catch NullPointerException or any of its ancestors 288
ERR09-J. Do not allow untrusted code to terminate the JVM 296
Chapter 9: Visibility and Atomicity (VNA) 301
Rules 301
Risk Assessment Summary 301
VNA00-J. Ensure visibility when accessing shared primitive variables 302
VNA01-J. Ensure visibility of shared references to immutable objects 306
VNA02-J. Ensure that compound operations on shared variables are atomic 309
VNA03-J. Do not assume that a group of calls to independently atomic methods is atomic 317
VNA04-J. Ensure that calls to chained methods are atomic 323
VNA05-J. Ensure atomicity when reading and writing 64-bit values 328
Chapter 10: Locking (LCK) 331
Rules 331
Risk Assessment Summary 332
LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code 332
LCK01-J. Do not synchronize on objects that may be reused 339
LCK02-J. Do not synchronize on the class object returned by getClass() 343
LCK03-J. Do not synchronize on the intrinsic locks of high-level concurrency objects 347
LCK04-J. Do not synchronize on a collection view if the backing collection is accessible 348
LCK05-J. Synchronize access to static fields that can be modified by untrusted code 351
LCK06-J. Do not use an instance lock to protect shared static data 352
LCK07-J. Avoid deadlock by requesting and releasing locks in the same order 355
LCK08-J. Ensure actively held locks are released on exceptional conditions 365
LCK09-J. Do not perform operations that can block while holding a lock 370
LCK10-J. Do not use incorrect forms of the double-checked locking idiom 375
LCK11-J. Avoid client-side locking when using classes that do not commit to their locking strategy 381
Chapter 11: Thread APIs (THI) 387
Rules 387
Risk Assessment Summary 387
THI00-J. Do not invoke Thread.run() 388
THI01-J. Do not invoke ThreadGroup methods 390
THI02-J. Notify all waiting threads rather than a single thread 394
THI03-J. Always invoke wait() and await() methods inside a loop 401
THI04-J. Ensure that threads performing blocking operations can be terminated 404
THI05-J. Do not use Thread.stop() to terminate threads 412
Chapter 12: Thread Pools (TPS) 417
Rules 417
Risk Assessment Summary 417
TPS00-J. Use thread pools to enable graceful degradation of service during traffic bursts 418
TPS01-J. Do not execute interdependent tasks in a bounded thread pool 421
TPS02-J. Ensure that tasks submitted to a thread pool are interruptible 428
TPS03-J. Ensure that tasks executing in a thread pool do not fail silently 431
TPS04-J. Ensure ThreadLocal variables are reinitialized when using thread pools 436
Chapter 13: Thread-Safety Miscellaneous (TSM) 441
Rules 441
Risk Assessment Summary 441
TSM00-J. Do not override thread-safe methods with methods that are not thread-safe 442
TSM01-J. Do not let the this reference escape during object construction 445
TSM02-J. Do not use background threads during class initialization 454
TSM03-J. Do not publish partially initialized objects 459
Chapter 14: Input Output (FIO) 467
Rules 467
Risk Assessment Summary 468
FIO00-J. Do not operate on files in shared directories 468
FIO01-J. Create files with appropriate access permissions 478
FIO02-J. Detect and handle file-related errors 481
FIO03-J. Remove temporary files before termination 483
FIO04-J. Close resources when they are no longer needed 487
FIO05-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code 493
FIO06-J. Do not create multiple buffered wrappers on a single InputStream 496
FIO07-J. Do not let external processes block on input and output streams 500
FIO08-J. Use an int to capture the return value of methods that read a character or byte 504
FIO09-J. Do not rely on the write() method to output integers outside the range 0 to 255 507
FIO10-J. Ensure the array is filled when using read() to fill an array 509
FIO11-J. Do not attempt to read raw binary data as character data 511
FIO12-J. Provide methods to read and write little-endian data 513
FIO13-J. Do not log sensitive information outside a trust boundary 516
FIO14-J. Perform proper cleanup at program termination 519
Chapter 15: Serialization (SER) 527
Rules 527
Risk Assessment Summary 528
SER00-J. Maintain serialization compatibility during class evolution 528
SER01-J. Do not deviate from the proper signatures of serialization methods 531
SER02-J. Sign then seal sensitive objects before sending them across a trust boundary 534
SER03-J. Do not serialize unencrypted, sensitive data 541
SER04-J. Do not allow serialization and deserialization to bypass the security manager 546
SER05-J. Do not serialize instances of inner classes 549
SER06-J. Make defensive copies of private mutable components during deserialization 551
SER07-J. Do not use the default serialized form for implementation-defined invariants 553
SER08-J. Minimize privileges before deserializing from a privileged context 558
SER09-J. Do not invoke overridable methods from the readObject() method 562
SER10-J. Avoid memory and resource leaks during serialization 563
SER11-J. Prevent overwriting of externalizable objects 566
Chapter 16: Platform Security (SEC) 569
Rules 569
Risk Assessment Summary 570
SEC00-J. Do not allow privileged blocks to leak sensitive information across a trust boundary 570
SEC01-J. Do not allow tainted variables in privileged blocks 574
SEC02-J. Do not base security checks on untrusted sources 577
SEC03-J. Do not load trusted classes after allowing untrusted code to load arbitrary classes 579
SEC04-J. Protect sensitive operations with security manager checks 582
SEC05-J. Do not use reflection to increase accessibility of classes, methods, or fields 585
SEC06-J. Do not rely on the default automatic signature verification provided by URLClassLoader and java.util.jar 592
SEC07-J. Call the superclass's getPermissions() method when writing a custom class loader 597
SEC08-J. Define wrappers around native methods 599
Chapter 17: Runtime Environment (ENV) 603
Rules 603
Risk Assessment Summary 603
ENV00-J. Do not sign code that performs only unprivileged operations 604
ENV01-J. Place all security-sensitive code in a single jar and sign and seal it 606
ENV02-J. Do not trust the values of environment variables 610
ENV03-J. Do not grant dangerous combinations of permissions 613
ENV04-J. Do not disable bytecode verification 617
ENV05-J. Do not deploy an application that can be remotely monitored 618
Chapter 18: Miscellaneous (MSC) 625
Rules 625
Risk Assessment Summary 625
MSC00-J. Use SSLSocket rather than Socket for secure data exchange 626
MSC01-J. Do not use an empty infinite loop 630
MSC02-J. Generate strong random numbers 632
MSC03-J. Never hard code sensitive information 635
MSC04-J. Do not leak memory 638
MSC05-J. Do not exhaust heap space 647
MSC06-J. Do not modify the underlying collection when an iteration is in progress 653
MSC07-J. Prevent multiple instantiations of singleton objects 657
Glossary 669
References 677
Index 693