Wiki Markup |
---|
It is imperative that sensitive data should be protected from eavesdropping and malicious tampering during transit. An Obfuscated Transfer Object \[[Steel 05|AA. Java References#Steel 05]\] can be used to encrypt data in exchanges that involve multiple business tiers or end user systems. Obfuscation can be achieved largely, by encrypting the sensitive object (sealing). This design pattern can further be supplemented to provide signature capabilities for guaranteeing object integrity. |
Signing and sealing objects takes preference over other similar measures is the preferred mechanism to secure data when:
- 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 interactionalternative for limited transactions
- Some sensitive data needs to persist over an extended period of time (for example, on an external hard drive)
- Implementing custom home-brewed cryptographic algorithms such as in the
readObject
andwriteObject
methods can leave the application exposed to security holes. It is advisable to not reinvent the broken wheel.vulnerable
Noncompliant Code Example
The This noncompliant 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 unravel the HashMap
containing sensitive social security numbers.
...
Code Block | ||
---|---|---|
| ||
class SignSealUtility implements Serializable { final long serialVersionUID = 2648720192864531932L; private HashMap ssnMap; private SealedObject sealedSsnMap; private SignedObject signedSsnMap; public SignSealUtility() { ssnMap = new HashMap(); } public void seal(Cipher cipher) throws Exception { sealedSsnMap = new SealedObject(ssnMap, cipher); // Now set the Map to null so that original data does not remain in cleartext ssnMap = null; } public void unseal(Cipher cipher) throws Exception { ssnMap = (HashMap)sealedSsnMap.getObject(cipher); } public void sign(Signature sig, PrivateKey key) throws Exception { signedSsnMap = new SignedObject(ssnMap, key, sig); ssnMap = null; } public void unsign(Signature sig, PublicKey key) throws Exception { if(signedSsnMap.verify(key, sig)) { ssnMap = (HashMap)signedSsnMap.getObject(); } } public Object getdata(Object key) throws Exception { return ssnMap.get(key); } public void setData(Object key, Object data) throws Exception { ssnMap.put(key, data); } } |
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 SEC32-J. Create and sign a SignedObject before creating a SealedObject)
...