https://www.oracle.com/technetwork/java/seccodeguide-139067.html
The language is type-safe,
and the runtime provides automatic memory management and bounds-checking on
arrays.
Java programs and libraries
check for illegal state at the earliest opportunity. These features also make
Java programs highly resistant to the stack-smashing [4] and
buffer overflow attacks
possible in the C and to a lesser extent C++ programming languages. The explicit static typing of
Java makes code easy to
understand (and facilitates static analysis), and the dynamic checks ensure unexpected conditions result in
predictable behavior.
To minimize the likelihood
of security vulnerabilities caused by programmer error, Java developers should
adhere to recommended coding guidelines.
Effective Java [6],
provide excellent guidelines related to Java software design.
Software Security: Building
Security In [7],
outline guiding principles for software security.
These guidelines are of
interest to all Java developers, whether they create trusted end-user
applications, implement the internals of a security component, or develop
shared Java class libraries that perform common programming tasks. Any
implementation bug can have serious security ramifications and could appear in
any layer of the software stack.
In order to reduce errors,
duplication should be minimized and
resource
handling concerns should be separated.
4 Accessibility and Extensibility
The task of securing a system is made easier by reducing the
"attack surface" of the code.
Guideline 4-2 / EXTEND-2: Limit
the accessibility of packages
This example code demonstrates how to append to the package.access security
property. Note that it is not
thread-safe. This
code should generally only appear once in a system.
private static final String PACKAGE_ACCESS_KEY =
"package.access";
static {
String packageAccess = java.security.Security.getProperty(
PACKAGE_ACCESS_KEY
);
java.security.Security.setProperty(
PACKAGE_ACCESS_KEY,
(
(packageAccess == null ||
packageAccess.trim().isEmpty()) ?
"" :
(packageAccess +
",")
) +
"xx.example.product.implementation."
);
}
When confirming an object's
class type by examining the java.lang.Class instance belonging to that object, do not
compare Class instances solely using class names
(acquired via Class.getName), because instances are scoped both by their
class name as well as the class loader that defined the class.
Guideline 6-2 / MUTABLE-2: Create
copies of mutable output values
To create a copy of a trusted mutable object,
call a copy constructor or the clone method:
public class CopyOutput { private final java.util.Date date; ... public java.util.Date getDate() { return (java.util.Date)date.clone(); } }
To create a copy of an untrusted mutable
object, call a copy constructor or creation method:
public final class CopyMutableInput { private final Date date; // java.util.Date is mutable public CopyMutableInput(Date date) { // create copy this.date = new Date(date.getTime()); } }
