Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

Classes that implement the Externalizable interface must provide the readExternal() and writeExternal() methods. These methods have package access -private or are public access, and so they can be called by trusted and hostile untrusted code alike. Consequently, programs must ensure that these methods execute only when intended , and that they cannot overwrite the internal state of objects at arbitrary points during program execution.

Noncompliant Code Example

This noncompliant code example allows any caller to reset the value of the object at any time , because the readExternal() method is necessarily declared to be public and lacks protection against hostile callers.:

Code Block
bgColor#FFcccc

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 protects against multiple initialization through the use of a Boolean flag that is set after the instance fields have been populated. It also protects against race - conditions by synchronizing on a private lock object (see LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code). It also protects against multiple initialization through the use of a boolean flag that is set after the instance fields have been populated.

Code Block
bgColor#ccccff

private final Object lock = new Object();
private boolean initialized = false;

public void readExternal(ObjectInput in)
                         throws IOException, ClassNotFoundException {
  synchronized (lock) {
    if (!initialized) {
      // Read instance fields
      this.name = (String) in.readObject();
      this.UID = in.readInt();
      // ...  
      initialized = true;
    } else {
      throw new IllegalStateException();
    }
  }
}

Note that this compliant solution is insufficient inadequate to protect sensitive data.

Risk Assessment

Failure to prevent the overwriting of an externalizable objects object can corrupt the state of the object.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SER13

SER11-J

low

Low

probable

Probable

low

Low

P6

L2

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="57957ee5-906b-4c54-9afe-fe1152da1c1d"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="27c82f53-8929-470e-ac89-c797dfc00520"><ac:plain-text-body><![CDATA[

[[Sun 2006

AA. Bibliography#Sun 06]]

"Serialization specification: A.7 Preventing Overwriting of Externalizable Objects"

]]></ac:plain-text-body></ac:structured-macro>

Automated Detection

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.SER11.IRXAvoid re-initializing fields in the 'readExternal()' method of 'Externalizable' classes

Bibliography

[API 2014]


[Sun 2006]

Serialization Specification, A.7, Preventing Overwriting of Externalizable Objects


...

Image Added Image Added Image AddedImage Removed      16. Serialization (SER)      49. Miscellaneous (MSC)