- 37. Do not shadow or obscure identifiers in subscopes
- 38. Do not declare more than one variable per declaration
- 39. Use meaningful symbolic constants to represent literal values in program logic
- 40. Properly encode relationships in constant definitions
- 41. Return an empty array or collection instead of a null value for methods that return an array or collection
- 42. Use exceptions only for exceptional conditions
- 43. Use a try-with-resources statement to safely handle closeable resources
- 44. Do not use assertions to verify the absence of runtime errors
- 45. Use the same type for the second and third operands in conditional expressions
- 46. Do not serialize direct handles to system resources
- 47. Prefer using iterators over enumerations
- 48. Do not use direct buffers for short-lived, infrequently used objects
- 49. Remove short-lived objects from long-lived container objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
46. Do not serialize direct handles to system resources
Serialized objects can be altered outside of any Java program unless they are protected using mechanisms such as sealing and signing. (See The CERT® Oracle® Secure Coding Standard for Java™ [Long 2012], “ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it.”) If an object referring to a system resource becomes serialized, and an attacker can alter the serialized form of the object, it becomes possible to modify the system resource that the serialized handle refers to. For example, an attacker may modify a serialized file handle to refer to an arbitrary file on the system. In the absence of a security manager, any operations that use the file handle will be carried out using the attacker-supplied file path and file name.
Noncompliant Code Example
This noncompliant code example declares a serializable File object in the class Ser:
final class Ser implements Serializable {
File f;
public Ser() throws FileNotFoundException {
f = new File("c:\\filepath\\filename");
}
}
The serialized form of the object exposes the file path, which can be altered. When the object is deserialized, the operations are performed using the altered path, which can cause the wrong file to be read or modified.
Compliant Solution (Not Implementing Serializable)
This compliant solution shows a final class Ser that does not implement java.io.Serializable. Consequently, the File object cannot be serialized.
final class Ser {
File f;
public Ser() throws FileNotFoundException {
f = new File("c:\\filepath\\filename");
}
}
Compliant Solution (Object Marked Transient)
This compliant solution declares the File object transient. The file path is not serialized with the rest of the class, and is consequently not exposed to attackers.
final class Ser implements Serializable {
transient File f;
public Ser() throws FileNotFoundException {
f = new File("c:\\filepath\\filename");
}
}
Applicability
Deserializing direct handles to system resources can allow the modification of the resources being referred to.
Bibliography
[Long 2012] |
ENV01-J. Place all security-sensitive code in a single JAR and sign and seal it |
[Oracle 2013c] |
Java Platform Standard Edition 7 Documentation |