Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The data is sensitive but its serialization or transportation is necessary
  • A secure communication channel such as SSL is absent or is a costly operation for a short interaction
  • Some sensitive data needs to persist over an extended period of time (for example, on an external hard drive)
  • Implementing custom cryptographic algorithms such as in the readObject and writeObject methods can leave the application exposed to security holes. It is advisable to not reinvent the broken wheel.

Noncompliant Code Example

The code in this noncompliant example is capable of being serialized and transferred across different business tiers. Unfortunately, there are no safeguards against byte stream manipulation attacks while the binary data is in transit. Likewise, anyone can reverse engineer the stream data from its hexadecimal notation to unroll the HashMap containing sensitive social security numbers.

Code Block
bgColor#FFcccc
class SimpleObject implements Serializable {
  final long serialVersionUID = -2648720192864531932L;
  private HashMap ssnMap;
  private SealedObject sealedSsnMap;

  public SimpleObject() {
    ssnMap = new HashMap();
  }

  public Object getdata(Object key) throws Exception {
    return ssnMap.get(key);
  }

  public void setData(Object key, Object data) throws Exception {
    ssnMap.put(key, data);
  }
}

Compliant Solution

To provide message confidentiality, use the javax.crypto.SealedObject class. This class encapsulates a serialized object and encrypts (or seals) it. A strong cryptographic algorithm that uses a secure cryptographic key and padding scheme must be employed to initialize the Cipher object parameter. The seal and unseal utility methods provide the encryption and decryption facilities respectively.

...

Note that the compliant solution throws a general Exception to limit the minutest of the information leaks that relate to the cryptographic implementation. Finally, one should refrain from signing encrypted (sealed) data. (See SEC09-J. Create and sign a SignedObject before creating a SealedObject)

Risk Assessment

Failure to sign and/or seal objects during transit can lead to loss of object integrity or confidentiality.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SEC08 SEC06-J

medium

probable

high

P4

L3

Automated Detection

TODO

Related Vulnerabilities

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

References

Wiki Markup
\[[API 06|AA. Java References#API 06]\] 
\[[Steel 05|AA. Java References#Steel 05]\] Chapter 10: Securing the Business Tier, Obfuscated Transfer Object
\[[Gong 03|AA. Java References#Gong 03]\] 9.10 Sealing Objects
\[[Harold 99|AA. Java References#Harold 99]\] Chapter 11: Object Serialization, Sealed Objects 
\[[Neward 04|AA. Java References#Neward 04]\] Item 64: Use SignedObject to provide integrity of Serialized objects and Item 65: Use SealedObject to provide confidentiality of Serializable objects
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 319|http://cwe.mitre.org/data/definitions/319.html] "Cleartext Transmission of Sensitive Information"

...