Page History

...

In this noncompliant code example, security manager checks are used within the constructor but are omitted from the writeObject() and readObject() methods that are used in the serialization-deserialization process. This allows untrusted code to maliciously create instances of the class. Despite the security manager checks, the data is not considered sensitive, as a sensitive serializable class would violate SER03-J. Do not serialize sensitive data.

We assume that AccessDeniedException and InvalidInputException are both security exceptions, and hence require no checkingare not checked. So any method can throw them without requiring a throws declaration.

Code Block

bgColor	#FFcccc

public final class CreditCardHometown implements Serializable {
  // Private internal state
  private String credit_cardtown;
  private static final String DEFAULTUNKNOWN = "DEFAULTUNKNOWN";

  void performSecurityManagerCheck() throws AccessDeniedException {
    // ...
  }

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

  public CreditCardHometown() {
    performSecurityManagerCheck();

    // Initialize credit_cardtown to default value
    credit_cardtown = DEFAULTUNKNOWN;
  }

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

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

  // writeObject() correctly enforces checks during serialization
  private void writeObject(ObjectOutputStream out) throws IOException {
    out.writeObject(credit_cardtown);
  }

  // readObject() correctly enforces checks during deserialization
  private void readObject(ObjectInputStream in) throws IOException {
    in.defaultReadObject();
    // If 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);
    }
  }
}

Compliant Solution

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

Code Block

bgColor	#ccccff

public final class CreditCardHometown implements Serializable {
  // ... all methods the same except the following:

  // writeObject() correctly enforces checks during serialization
  private void writeObject(ObjectOutputStream out) throws IOException {
    performSecurityManagerCheck();
    out.writeObject(credit_cardtown);
  }

  // readObject() correctly enforces checks during deserialization
  private void readObject(ObjectInputStream in) throws IOException {
    in.defaultReadObject();
    // If 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);
    }
  }
}

Refer to guideline SEC08-J. Protect sensitive operations with security manager checks to learn about implementing the performSecurityManagerCheck() method. As with guideline SER04-J. Validate deserialized objects, it is important to protect against the finalizer attack.

...

Allowing serialization or deserialization to bypass the Security Manager may result in sensitive data being exposed or modifiedclasses being constructed without requird security checks.

Guideline	Severity	Likelihood	Remediation Cost	Priority	Level
SER05-J	high	probable	high	P6	L2

...

Space shortcuts

Page tree

Versions Compared

Old Version 53

New Version 54

Key

Compliant Solution