Versions Compared

Key

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

The serialization Serialization and deserialization features can be exploited to bypass security manager checks. A serializable class may employ contain security manager checks in its constructors for various reasons. For example, the checks prevent an attacker , including preventing untrusted code from modifying the internal state of the class. Such security manager checks must be replicated wherever a class instance can be constructed. For example, if a class enables a caller to retrieve sensitive internal state contingent upon security checks, those checks must be replicated during deserialization to ensure that an attacker cannot extract sensitive information by deserializing the object.

Noncompliant Code Example

In this noncompliant code example, security manager checks are used within the constructor but are not replicated throughout, specifically, within the readObject and writeObject omitted from the writeObject() and readObject() methods that are used in the serialization-deserialization process. This omission allows an attacker untrusted code to maliciously create instances of the class that bypass security manager checks when deserialization is performed.

Code Block
bgColor#FFcccc

public final class CreditCardHometown implements java.io.Serializable {

  //private Private internal state
  private String credit_cardtown;
  private static final String DEFAULTUNKNOWN = "DEFAULTUNKNOWN";

  public CreditCardvoid performSecurityManagerCheck() throws AccessDeniedException {
    // ...
  }

  void validateInput(String newCC) throws InvalidInputException {
    // ...
  }

  public Hometown() {
    performSecurityManagerCheck();

    //initialize credit_card Initialize town to default value
    credit_card = DEFAULTtown = UNKNOWN;
  }

  // Allows callers to retrieve internal state
  String getValue() {
    performSecurityManagerCheck();
    return town;
  }

  //allows Allows callers to modify (private) internal state
  public void changeCCchangeTown(String newCCnewTown) {
    if (credit_cardtown.equals(newCCnewTown)) {
      // noNo change
      return;
    } else {  
      performSecurityManagerCheck();
      validateInput(newCCnewTown);
      credit_cardtown = newCCnewTown;
    }
  }

  private void writeObject(ObjectOutputStream out)  // readObject correctly enforces checks during deserializationthrows IOException {
    out.writeObject(town);
  }

  private void readObject(java.io.ObjectInputStream in) throws IOException {
    in.defaultReadObject();
    // ifIf the deserialized name does not match the default value normally
    // created at construction time, duplicate the checks
    if (!DEFAULTUNKNOWN.equals(credit_cardtown)) {
      validateInput(credit_cardtown);
    }
  }

  // allows callers to retrieve internal state
  public String getValue() {
    return somePublicValue;
  }

  // writeObject correctly enforces checks during serialization
  private void writeObject(java.io.ObjectOutputStream out) {
    out.writeObject(credit_card);
  }
}

Compliant Solution

}

(Although there are security manager checks, the data in this example is not sensitive. Serializing unencrypted sensitive data violates SER03-J. Do not serialize unencrypted sensitive data.)

AccessDeniedException and InvalidInputException are both security exceptions that can be thrown by any method without requiring a throws declaration.

Compliant Solution

This compliant solution implements the required The compliant solution correctly implements security manager checks in all constructors , and methods that can either modify internal state and methods that or retrieve internal state. As a resultConsequently, an attacker cannot create an a modified instance of the object with modified state (using deserialization) and cannot simply or read the serialized byte stream to uncover sensitive data (using serialization)reveal serialized data.

Code Block
bgColor#ccccff

public final class SecureCreditCardHometown implements java.io.Serializable {

  //private internal state
  private String credit_card;
  private static final String DEFAULT = "DEFAULT";... All methods the same except the following:

  public// SecureCreditCardwriteObject() {
correctly enforces checks  //initialize credit_card to default value
    credit_card = DEFAULT;
  }

  //allows callers to modify (private) internal state
  public void changeCC(String newCC) {
    if (credit_card.equals(newCC))during serialization
  private void writeObject(ObjectOutputStream out) throws IOException {
      // no change
      return;
    } else {
      // check permissions to modify credit_card
      performSecurityManagerCheck();
      validateInput(newCCout.writeObject(town);
      credit_card = newCC;
    }
  }

  // readObject() correctly enforces checks during deserialization
  private void readObject(java.io.ObjectInputStream in) throws IOException {
    in.defaultReadObject();
    // ifIf the deserialized name does not match the default value normally
    // created at construction time, duplicate the checks
    if (!DEFAULTUNKNOWN.equals(credit_cardtown)) {
      performSecurityManagerCheck();
      validateInput(credit_cardtown);
    }
  }

  // allows callers to retrieve internal state
  public String getValue() {
  // check permission to get value
    performSecurityManagerCheck();
    return somePublicValue;
  }

  // writeObject correctly enforces checks during serialization
  private void writeObject(java.io.ObjectOutputStream out) {
    // duplicate check from getValue()
    performSecurityManagerCheck();
    out.writeObject(credit_card);
  }
}

Risk Assessment

}

Refer to SEC04-J. Protect sensitive operations with security manager checks for information about implementing the performSecurityManagerCheck() method, which is important for protection against finalizer attacks.

The ObjectInputStream.defaultReadObject() fills the object's fields with data from the input stream. Because each field is deserialized recursively, it is possible for the this reference to escape from control of the deserialization routines. This can happen if a referenced object publishes the this reference in its constructors or field initializers (see TSM01-J. Do not let the this reference escape during object construction for more information). To be compliant, recursively deserialized subobjects must not publish the this object reference.

Risk Assessment

Allowing serialization or deserialization to bypass the security manager may result in classes being constructed without required security checks.TODO

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

FIO33

SER04-J

??

High

??

Probable

??

P??

L??

High

P6

L2

Automated Detection

...

TODO

Related Vulnerabilities

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

References

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.SER04.SCSEREnforce 'SecurityManager' checks in methods of 'Serializable' classes

Related Guidelines

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 8-4 / SERIAL-4: Duplicate the SecurityManager checks enforced in a class during serialization and deserialization

Android Implementation Details

The java.security package exists on Android for compatibility purposes only, and it should not be used.

Bibliography

[Long 2005]

Section 2.4, "Serialization"


...

Image Added Image Added Image AddedSun Secure Coding Guidelines