The document discusses various techniques for writing secure Java code. It covers topics like ensuring classes are final by default to prevent breaking invariants, declaring data members as private and providing accessible wrapper methods, not using public static nonfinal variables, being wary of constructors that throw exceptions, not signing code that only performs unprivileged operations, placing all security sensitive code in a single signed JAR file, not trusting environment variable values, avoiding granting dangerous permission combinations, not disabling bytecode verification, and not deploying remotely monitorable applications.

1. Secure Coding In Java
By : Abhishek Nigam
Cybage Software Pvt. Ltd.

2. JAVA

3. ●
Java is a computer programming language that is concurrent, class­
based, object­oriented, and specifically designed to have as few
implementation dependencies as possible
●
It is intended to let application developers "write once, run
anywhere" (WORA), meaning that code that runs on one platform
does not need to be recompiled to run on another.
●
Java applications are typically compiled to bytecode (class file) that
can run on any Java virtual machine (JVM) regardless of computer
architecture.
●
Java is, as of 2014, one of the most popular programming languages
in use, particularly for client­server web applications, with a reported
9 million developers.
●
Java was originally developed by James Gosling at Sun
Microsystems (which has since merged into Oracle Corporation) and
released in 1995 as a core component of Sun Microsystems' Java
platform.

4. ●
There were five primary goals in the creation of the Java language:
a. It should be "simple, object­oriented and familiar"
b. It should be "robust and secure"
c. It should be "architecture­neutral and portable"
d. It should execute with "high performance"
e. It should be "interpreted, threaded, and dynamic"
Java is a relatively secure language. It has no explicit pointer manipulation;
array and string bounds are automatically checked; attempts at referencing a
null pointer are trapped; the arithmetic operations are well defined and
platform independent, as are the type conversions. The built­in bytecode
verifier ensures that these checks are always in place.

5. JIT(Just­In­Time)
●
A common implementation of JIT compilation is to first have AOT
compilation to bytecode (virtual machine code), known as bytecode
compilation, and then have JIT compilation to machine code
(dynamic compilation), rather than interpretation of the bytecode.
●
This improves the runtime performance compared to interpretation.
●
JIT compilers translate continuously, as with interpreters, but
caching of compiled code minimizes lag on future execution of the
same code during a given run.

6. Security Manager
●
The security manager is a class that allows applications to implement a
security policy.
●
It allows an application to determine, before performing a possibly unsafe or
sensitive operation, what the operation is and whether it is being attempted
in a security context that allows the operation to be performed.
●
Security manager routine simply returns if the operation is permitted, but
throws a SecurityException if the operation is not permitted.
●
The special method checkPermission(java.security.Permission) determines
whether an access request indicated by a specified permission should be
granted or denied. The default implementation calls
“AccessController.checkPermission(perm)”

7. ●
The policy configuration file(s) for a JDK or JRE installation specifies
what permissions (which types of system resource accesses) are
granted to code from a specified code source, and executed as a
specified principal.
●
For an applet (or an application running under a security manager)
to be allowed to perform secured actions (such as reading or writing
a file), the applet (or application) must be granted permission for
that particular action. In the Policy reference implementation, that
permission must be granted by a grant entry in a policy
configuration file.

8. Object Orientation (OBJ)

9. Limit extensibility of classes and methods with
invariants
●
Many classes also offer invariants, which are guarantees made about the state of their
objects' fields upon the completion of any of their methods
●
A subclass can fail to satisfy the invariants promised to clients by its superclass, and it
can break the internal invariants on which the superclass relies. For instance, an
immutable class that lacks the final qualifier can be extended by a malicious subclass.
●
To mitigate these risks, classes must be declared final by default. Developers should
permit extensibility only when there is a perceived need for it and must.
●
The java.math.BigInteger class is itself an example of noncompliant code. It is non­final
and consequently extendable. This can be a problem when operating on an instance
of BigInteger that was obtained from an untrusted client.

10. Limit extensibility of classes and methods with
invariants
●
Many classes also offer invariants, which are guarantees made about the state of their
objects' fields upon the completion of any of their methods
●
A subclass can fail to satisfy the invariants promised to clients by its superclass, and it
can break the internal invariants on which the superclass relies. For instance, an
immutable class that lacks the final qualifier can be extended by a malicious subclass.
●
To mitigate these risks, classes must be declared final by default. Developers should
permit extensibility only when there is a perceived need for it and must.
●
The java.math.BigInteger class is itself an example of noncompliant code. It is non­final
and consequently extendable. This can be a problem when operating on an instance
of BigInteger that was obtained from an untrusted client.

11. Declare data members as private and provide
accessible wrapper methods
● It is difficult to control how data members declared public or
protected are accessed. Attackers can manipulate such members
in unexpected ways. As a result data members must be declared
private.

12. Do not use public static nonfinal variables
●
Client code can trivially access public static fields. Neither reads nor
writes to such variables are checked by a security manager.
●
New values cannot be validated programmatically before they are
stored in these fields.
●
Improper use of public static fields can also result in type­safety
issues.
●
Untrusted code can supply an unexpected subtype with malicious
methods when the variable is defined to be of a more general type,
such as java.lang.Object

13. Be wary of letting constructors throw exceptions
●
An object is partially initialized if a constructor has begun building
the object but has not finished. As long as the object is not fully
initialized, it must be hidden from other classes.
●
There are three common approaches to dealing with the problem of
partially initialized objects:
●
Exception in constructor. One approach is to throw an exception in
the object's constructor. Unfortunately, an attacker can maliciously
obtain the instance of such an object.
●
Final field. Declaring the variable that is initialized to the object as
final prevents the object from being partially initialized.
●

14. Runtime Environment (ENV)

15. Do not sign code that performs only unprivileged
operations
●
Java applets can escape the default sandbox restrictions when signed.
●
For example, signed Java applets. When a certificate is verified, on
widely used platforms, the user is presented with a security dialog in
which the option "Always trust the content from the publisher" is
selected by default.
●
An attacker can take advantage of this mechanism by exploiting
vulnerable code signed by the trusted organization.
●
Oracle has deprecated the use of unsigned applets, and will cease to
support them soon.
●
Since Java 1.7.0 update 25, Oracle has provided mechanisms to allow
applets to be signed, and yet run without full permissions. This enables
applets that are today unsigned to continue to run in a security sandbox,
despite being signed.

16. Place all security­sensitive code in a single JAR
and sign and seal it
●
If an attacker can link security­sensitive code with malicious code, he
or she can indirectly cause incorrect behavior. This is called a mix­
and­match attack.
●
Privileged code may use a class that exists in an untrusted container
and performs only unprivileged operations.
●
If the attacker were to replace the class in the untrusted container
with a malicious class, the trusted code might receive incorrect
results and misbehave at the discretion of the malicious code.
●
“A package sealed within a JAR specifies that all classes defined in
that package must originate from the same JAR. Otherwise, a
SecurityException is thrown.”

17. Do not trust the values of environment variables
●
Programs that execute in a more trusted domain than their environment
must assume that the values of environment variables are untrusted and
must sanitize and validate any environment variable values before use.
●
The default values of system properties are set by the Java Virtual Machine
(JVM) upon startup and can be considered trusted.
●
However, they may be overridden by properties from untrusted sources,
such as a configuration file. System properties from untrusted sources must
be sanitized and validated before use.
●
An attacker can essentially control all environment variables that enter a
program using a mechanism such as the java.lang.ProcessBuilder class.

18. Do not grant dangerous combinations of
permissions
●
“All Permission” :­ The permission java.security.AllPermission grants all
possible permissions to code.
●
Code is typically granted AllPermission via the security policy file
●
“ReflectPermission, suppressAccessChecks” :­ Granting ReflectPermission
on the target suppressAccessChecks suppresses all standard Java language
access checks when the permitted class attempts to operate on package­
private, protected, or private members of another class.
●
The permitted class can obtain permissions to examine any field or invoke
any method belonging to an arbitrary class.
●
“RuntimePermission, createClassLoader” :­The permission
java.lang.RuntimePermission applied to target createClassLoader grants code
the permission to create a ClassLoader object.
●
This is extremely dangerous because malicious code can create its own
custom class loader and load classes by assigning them arbitrary permissions.

19. Do not disable bytecode verification
●
When Java source code is compiled, it is converted into bytecode,
saved in one or more class files, and executed by the JVM. Java class
files may be compiled on one machine and executed on another
machine.
●
The Java bytecode verifier is an internal component of the JVM that
is responsible for detecting nonconforming Java bytecode.
●
The bytecode verifier must not be suppressed.
●
To supress bytecode verifier :­ “java ­Xverify:none ApplicationName”

20. Do not deploy an application that can be remotely
monitored
●
The JVMTI (JVM Tool Interface)contains extensive facilities to learn
about the internals of a running JVM, including facilities to monitor
and modify a running Java program.
●
The JVMTI profiling tools can also measure the time that a thread
takes to execute, leaving applications vulnerable to timing attacks.
●
The JVMTI is always enabled, and JVMTI agents may run under the
default security manager without requiring any permissions to be
granted.
●
The Java Platform Debugger Architecture (JPDA) builds on the
JVMTI and provides high­level facilities for debugging Java systems
while they are running
●
The JPDA facilities are similar to the reflection API

21. Production code must not contain debugging entry
points
●
A common development practice is to add "back door" code
specifically designed for debugging or testing purposes that is not
intended to be shipped or deployed with the application.
●
These back door entry points create security risks because they are
not considered during design or testing and fall outside of the
expected operating conditions of the application.

22. Methods(MET)

23. Validate method arguments
●
This practice ensures that operations on the method's parameters
yield valid results. Failure to validate method arguments can result
in incorrect calculations, runtime exceptions, violation of class
invariants, and inconsistent object state.
●
Caller validation of arguments can result in faster code because the
caller may be aware of invariants that prevent invalid values from
being passed.

24. Do not use deprecated or obsolete classes or
methods
●
Java also provides a @deprecated annotation to indicate the
deprecation of specific fields, methods, and classes.
●
For instance, many methods of java.util.Date, such as Date.getYear(),
have been explicitly deprecated.
●
E.g of deprecated methods :­ java.lang.Thread.run(),
java.lang.Thread.stop(), java.lang.ThreadGroup (many methods).

25. Methods that perform a security check must be
declared private or final
●
Non­final member methods that perform security checks can be
compromised when a malicious subclass overrides the methods and
omits the checks.

26. Do not increase the accessibility of overridden or
hidden methods
●
Increasing the accessibility of overridden or hidden methods permits
a malicious subclass to offer wider access to the restricted method
than was originally intended.

27. Ensure that constructors do not call overridable
methods
●
Invocation of an overridable method during object construction may
result in the use of uninitialized data, leading to runtime exceptions
or to unanticipated outcomes.
●
Calling overridable methods from constructors can also leak the this
reference before object construction is complete, potentially
exposing uninitialized or inconsistent data to other threads.
●
Constructors must invoke only methods that are final or private.

28. Do not invoke overridable methods in clone()
●
A malicious subclass could override the method and affect the
behavior of the clone() method.
●
A trusted subclass could observe (and potentially modify) the cloned
object in a partially initialized state before its construction has
concluded.
●
The subclass could leave the clone, the object being cloned, or both
in an inconsistent state. Consequently, clone() methods may invoke
only methods that are final or private.

29. ●
By default, java cloning is ‘field by field copy’ i.e. as the Object class
does not have idea about the structure of class on which clone()
method will be invoked. So, JVM when called for cloning, do
following things:
1) If the class has only primitive data type members then a
completely new copy of the object will be created and the reference
to the new object copy will be returned.
2) If the class contains members of any class type then only the
object references to those members are copied and hence the
member references in both the original object as well as the cloned
object refer to the same object.

30. Never declare a class method that hides a method
declared in a superclass or superinterface
●
When a class declares a static method m, the declaration of m hides
any method m', where the signature of m is a subsignature of the
signature of m' and the declaration of m' is both in the superclasses
and superinterfaces of the declaring class and also would otherwise
be accessible to code in the declaring class.
●
Hiding and overriding differ in the determination of which method is
invoked from a call site.

31. Classes that define an equals() method must also
define a hashCode() method
●
Classes that override the Object.equals() method must also override
the Object.hashCode() method.
●
The java.lang.Object class requires that any two objects that compare
equal using the equals() method must produce the same integer
result when the hashCode() method is invoked on the objects
●
The equals() method is used to determine logical equivalence
between object instances.
●
The contract between hashCode and equals method:­
“if two objects are equal, that is obj1.equals(obj2) is true then,
obj1.hashCode() and obj2.hashCode() must return same integer”
●
hashCode() and getClass() are native methods.

32. Ensure that keys used in comparison operations
are immutable
●
Objects that serve as keys in ordered sets and maps should be
immutable. When some fields must be mutable, the equals(),
hashCode(), and compareTo() methods must consider only
immutable state when comparing objects.
●
The documentation of java.util.Interface Set<E> and
java.util.Interface Map<K,V> warns against this.

33. ●
great care must be exercised when mutable objects are used as map
keys. The behavior of a map is not specified if the value of an object
is changed in a manner that affects equals comparisons while the
object is a key in the map.
●
A special case of this prohibition is that it is not permissible for a
map to contain itself as a key. While it is permissible for a map to
contain itself as a value, extreme caution is advised: the equals and
hashCode methods are no longer well defined on such a map.

34. Do not use finalizers
●
The garbage collector invokes object finalizer methods after it determines that
the object is unreachable but before it reclaims the object's storage. Execution of
the finalizer provides an opportunity to release resources such as open streams,
files, and network connections that might not otherwise be released
automatically through the normal action of the garbage collector.
●
There is no fixed time at which finalizers must be executed because this depends
on the JVM.
●
The only guarantee is that any finalizer method that executes will do so
sometime after the associated object has become unreachable (detected during
the first cycle of garbage collection) and sometime before the garbage collector
reclaims the associated object's storage (during the garbage collector's second
cycle).
●
The JVM may terminate without invoking the finalizer on some or all
unreachable objects.

35. ●
Uncaught exceptions thrown during finalization are ignored. When
an exception thrown in a finalizer propagates beyond the finalize()
method, the process itself immediately stops and consequently fails
to accomplish its sole purpose.
●
Coding errors that result in memory leaks can cause objects to
incorrectly remain reachable.
●
A programmer can unintentionally resurrect an object's reference in
the finalize() method. When this occurs, the garbage collector must
determine yet again whether the object is free to be deallocated.
Further, because the finalize() method has executed once, the
garbage collector cannot invoke it a second time.

36. ●
Finalizers increase garbage­collection time and introduce space overheads.
●
Use of finalizers can introduce synchronization issues even when the
remainder of the program is single­threaded.
●
Use of locks or other synchronization­based mechanisms within a finalizer
can cause deadlock or starvation.
●
Exceptions :­
Finalizers may be used when working with native code because the
garbage collector cannot reclaim memory used by code written in
another language and because the lifetime of the object is often
unknown. Again, the native process must not perform any critical jobs
that require immediate resource deallocation.

37. Thread API

38. Do not invoke Thread.run()
●
Invoking the Thread.start() method instructs the Java runtime to
start executing the thread's run() method using the started thread
●
When a Thread object's run() method is invoked directly, the
statements in the run() method are executed by the current thread
rather than by the newly created thread.
●
If the Thread object was constructed by instantiating a subclass of
Thread that fails to override the run() method ,then any calls to the
subclass's run() method would invoke Thread.run(), which does
nothing.
●
Exceptions :­ The run() method may be directly invoked during unit
testing.

39. Do not invoke ThreadGroup methods
●
Each thread in Java is assigned to a thread group upon the thread's
creation. These groups are implemented by the
java.lang.ThreadGroup class. When the thread group name is not
specified explicitly, the main default group is assigned by the Java
Virtual Machine.
●
Many of the methods of the ThreadGroup class are deprecated (for
example, allowThreadSuspension(), resume(), stop(), and
suspend()).
●
Few ThreadGroup methods are not even thread­safe.

40. ●
ThreadGroup.activeCount() :­ Threads that have never started
nevertheless reside in the thread group and are considered to be
active. The active count is also affected by the presence of certain
system threads.
●
The enumerate() method :­ It copies into the specified array every
active thread in this thread group and its subgroups. An application
should use the activeCount method to get an estimate of how big the
array should be. If the array is too short to hold all the threads, the
extra threads are silently ignored.
●
Stop() method :­ An application may have to maintain its own list of
the threads it creates because simply inspecting the ThreadGroup
may return library threads that do not terminate and for which join
will not return.

41. Notify all waiting threads rather than a single
thread
●
The notify() method wakes up only one thread, with no guarantee
regarding which specific thread is notified.
●
Invoking the notify() method is permitted only when all of the
following conditions are met:
a. All waiting threads have identical condition predicates.
b. All threads perform the same set of operations after waking up.
That is, any one thread can be selected to wake up and resume for a
single invocation of notify().
c. Only one thread is required to wake upon the notification.

42. Ensure that threads performing blocking
operations can be terminated
●
Threads and tasks that block on operations involving network or file
I/O must provide callers with an explicit termination mechanism to
prevent DoS vulnerabilities.

43. Do not use Thread.stop() to terminate threads
●
The Thread.stop() method causes the thread to immediately throw a
ThreadDeath exception, which usually stops the thread.
●
Invoking Thread.stop() results in the release of all locks a thread has
acquired, potentially exposing the objects protected by those locks
when those objects are in an inconsistent state.
●
Removing the java.lang.RuntimePermission stopThread permission
from the security policy file prevents threads from being stopped
using the Thread.stop() method.

44. Exceptional Behavior (ERR)

45. Do not suppress or ignore checked exceptions
●
Programmers often suppress checked exceptions by catching
exceptions with an empty or trivial catch block.
●
Each catch block must ensure that the program continues only with
valid invariants.
●
no part of any expression or statement that occurs in the try block
after the point from which the exception is thrown is evaluated.
●
when the client cannot be expected to recover from the underlying
problem, it is good practice to allow the exception to propagate
outwards rather than to catch and suppress the exception.

46. Do not allow exceptions to expose sensitive
information
●
Failure to filter sensitive information when propagating exceptions
often results in information leaks that can assist an attacker's efforts
develop further exploits.
●
For example, the FileNotFoundException message reveals information
about the file system layout, and the exception type reveals the
absence of the requested file.
●
In 2004, Schanefeld discovered an exploit for the Opera v7.54 web
browser in which an attacker could use the
sun.security.krb5.Credentials class in an applet as an oracle to
"retrieve the name of the currently logged in user and parse his home
directory from the information which is provided by the thrown
java.security.AccessControlException"

47. ●
Common Exceptions which may cause harm :­
a) java.io.FileNotFoundException :­ Underlying file system structure,
user name enumeration
b) java.sql.SQLException :­ Database structure, user name enumeration
c) java.lang.OutOfMemoryError :­ DoS
d) java.lang.StackOverflowError :­ DoS
●
Printing the stack trace can also result in unintentionally leaking
information about the structure and state of the process to an attacker.

48. Prevent exceptions while logging data
●
Exceptions that are thrown while logging is in progress can prevent
successful logging unless special care is taken.
●
Failure to account for exceptions during the logging process can
cause security vulnerabilities, such as allowing an attacker to conceal
critical security exceptions by preventing them from being logged.

49. Restore prior object state on method failure
●
Objects in general should — and security­critical objects must — be
maintained in a consistent state even when exceptional conditions
arise.
●
Common techniques for maintaining object consistency include
a. Input validation (on method arguments, for example)
b. Reordering logic so that code that can result in the exceptional
condition executes before the object is modified
c. Using rollbacks in the event of failure
d. Performing required operations on a temporary copy of the object
and committing changes to the original object only after their
successful completion
e. Avoiding the need to modify the object at all

50. Do not complete abruptly from a finally block
●
Never use return, break, continue, or throw statements within a
finally block.
●
Statements that cause the finally block to complete abruptly also
cause the try block to complete abruptly and consequently suppress
any exception thrown from the try or catch blocks.

51. Do not let checked exceptions escape from a
finally block
●
Methods invoked from within a finally block can throw an exception.
Failure to catch and handle such exceptions results in the abrupt
termination of the entire try block.
●
the transfer of control associated with the exception may prevent
execution of any expressions or statements that occur after the point
in the finally block from which the exception is thrown.

52. Do not throw RuntimeException, Exception, or
Throwable
●
Handling these exceptions requires catching RuntimeException.
●
throwing a RuntimeException can lead to subtle errors; for example,
a caller cannot examine the exception to determine why it was
thrown and consequently cannot attempt recovery.
●
Methods can throw a specific exception subclassed from Exception or
RuntimeException.

53. Do not catch NullPointerException or any of its
ancestors
●
A NullPointerException exception thrown at runtime indicates the
existence of an underlying null pointer dereference that must be
fixed in the application code
●
Catching NullPointerException adds significantly more performance
overhead than simply adding the necessary null checks
●
When multiple expressions in a try block are capable of throwing a
NullPointerException, it is difficult or impossible to determine which
expression is responsible for the exception
●
Programs rarely remain in an expected and usable state after a
NullPointerException has been thrown.

54. Do not allow untrusted code to terminate the JVM
●
Invocation of System.exit() terminates the Java Virtual Machine
(JVM), consequently terminating all running programs and threads.
●
This can result in denial­of­service (DoS) attacks.
●
A call to System.exit() that is embedded in Java Server Pages (JSP)
code can cause a web server to terminate, preventing further service
for users.
●
Programs must prevent both inadvertent and malicious calls to
System.exit().

55. Input Output (FIO)

56. Create files with appropriate access permissions
●
File systems use a privileges and permissions model to protect file
access.
●
When a program creates a file with insufficiently restrictive access
permissions, an attacker may read or modify the file before the
program can modify the permissions.
●
files must be created with access permissions that prevent
unauthorized file access.

57. Detect and handle file­related errors
●
Java's file­manipulation methods often indicate failure with a return
value instead of throwing an exception.
●
Programs that ignore the return values from file operations often fail
to detect that those operations have failed.
●
Java programs must check the return values of methods that perform
file I/O.

58. Remove temporary files before termination
●
Temporary files can be used to :­
a. share data between processes.
b. store auxiliary program data (for example, to preserve memory).
c. construct and/or load classes, JAR files, and native libraries
dynamically.
●
Removing temporary files when they are no longer required allows
file names and other resources (such as secondary storage) to be
recycled.
●
Removing temporary files when they are no longer required allows
file names and other resources (such as secondary storage) to be
recycled. These utilities are themselves frequently vulnerable to file­
based exploits.

59. Release resources when they are no longer needed
●
The garbage collector cannot free non­memory resources such as
open file descriptors and database connections.
●
Failing to release such resources can lead to resource exhaustion
attacks.
●
Programs can experience resource starvation while waiting for
finalize() to release resources such as Lock or Semaphore objects.
●
Output streams may cache object references; such cached objects are
not garbage­collected until after the output stream is closed.

60. Do not operate on untrusted file links
●
Multiuser systems allow several users with different privileges to
share a file system. Each user in such an environment must be able
to determine which files are shared and which are private, and each
user must be sure of the results of these decisions.
●
Wide variety of file system vulnerabilities can be exploited by an
attacker to gain access to files for which they lack sufficient
privileges, particularly when operating on files that reside in shared
directories in which multiple users may create, move, or delete files.
●
A number of file system properties and capabilities can be exploited
by an attacker, one of which is file links.

61. try {
BasicFileAttributes attr = Files.readAttributes(
path, BasicFileAttributes.class, LinkOption.NOFOLLOW_LINKS);
// Check
if (!attr.isRegularFile()) {
System.out.println("Not a regular file");
return;
}

62. Serialization (SER)

63. Do not deviate from the proper signatures of
serialization methods
●
private void writeObject(java.io.ObjectOutputStream out) throws
IOException;
●
private void readObject(java.io.ObjectInputStream in) throws
IOException, ClassNotFoundException;
●
private void readObjectNoData() throws ObjectStreamException;

64. ●
Serializable Interface is a marker interface.
●
These methods must be declared private for any serializable class.
●
Deviating from these method signatures produces a method that is not
invoked during object serialization or deserialization.
●
Serializable does not define the method signatures it requires.
Interfaces allow only public fields and methods, whereas readObject(),
readObjectNoData, and writeObject() must be declared private
●
The Java serialization mechanism fails to let the compiler identify an
incorrect method signature for any of these methods.

65. Do not serialize instances of inner classes
●
An inner class is a nested class that is not explicitly or implicitly
declared static . Serialization of inner classes (including local and
anonymous classes) is error prone.
●
Serializing an inner class declared in a non­static context that
contains implicit non­transient references to enclosing class instances
results in serialization of its associated outer class instance.

66. Do not serialize unencrypted, sensitive data
●
serialization allows an object's state to be saved as a sequence of
bytes and then reconstituted at a later time, it provides no
mechanism to protect the serialized data.
●
An attacker who gains access to the serialized data can use it to
discover sensitive information and to determine implementation
details of the objects.
●
An attacker can also modify the serialized data in an attempt to
compromise the system when the malicious data is deserialized.
●
Sensitive data that should never be serialized include cryptographic
keys, digital certificates, and classes that may hold references to
sensitive data at the time of serialization.