If a class implements Externalizable
, the readExternal()
and writeExternal()
methods must be provided. Unfortunately, these methods are public
and, consequently, can be called by hostile code capable of overwriting the internal state of the object at any point during program execution.
Noncompliant Code Example
This noncompliant code example allows anyone to reset the value of the object because of the public
access modifier of the readExternal()
method.
public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { // Read instance fields this.name = (String)in.readObject(); this.UID = in.readInt(); //... }
Compliant Solution
This compliant solution is thread-safe and allows the caller to check the initialized
flag after which the instance fields are populated. Finally, the flag is set to true
so that the fields cannot be overwritten.
public synchronized void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { if (!initialized) { // Read instance fields this.name = (String)in.readObject(); this.UID = in.readInt(); //... initialized = true; } else { throw new IllegalStateException(); } }
Risk Assessment
Failure to prevent the overwriting of externalizable objects can corrupt the state of the object.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
SER13-J |
low |
probable |
low |
P6 |
L2 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
[[API 2006]]
[[Sun 2006]] "Serialization specification: A.7 Preventing Overwriting of Externalizable Objects"
SER12-J. Avoid memory and resource leaks during serialization 16. Serialization (SER) 49. Miscellaneous (MSC)