The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid. It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions if it does not use cryptography to protect itself. Furthermore, any cryptography would still be client-side security -- which is a dangerous security assumption. Data that is untrusted can not be trusted to be well-formed. 1000 699 Weakness ChildOf 485 844 Category ChildOf 858 888 Category ChildOf 896 Architecture and Design Implementation Medium Availability DoS: resource consumption (CPU) If a function is making an assumption on when to terminate, based on a sentry in a string, it could easily never terminate. Authorization Other Other Code could potentially make the assumption that information in the deserialized object is valid. Functions which make this dangerous assumption could be exploited. Requirements A deserialization library could be used which provides a cryptographic framework to seal serialized data. Implementation Use the signing features of a language to assure that deserialized data has not been tainted. Implementation When deserializing data populate a new object rather than just deserializing, the result is that the data flows through safe input validation and that the functions are safe. Implementation Explicitly define final readObject() to prevent deserialization. An example of this is: Java private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Cannot be deserialized"); } Architecture and Design Implementation Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly. This code snippet deserializes an object from a file and uses it as a UI button: Java try { File file = new File("object.obj"); ObjectInputStream in = new ObjectInputStream(new FileInputStream(file)); javax.swing.JButton button = (javax.swing.JButton) in.readObject(); in.close(); } This code does not attempt to verify the source or contents of the file before deserializing it. An attacker may be able to replace the intended file with a file that contains arbitrary malicious code which will be executed when the button is pressed. Deserialization of untrusted data Do not deviate from the proper signatures of serialization methods SER01-J Do not serialize unencrypted, sensitive data SER03-J Make defensive copies of private mutable components during deserialization SER06-J Do not use the default serialized form for implementation defined invariants SER08-J CLASP Eric Dalci Cigital 2008-07-01 updated Time_of_Introduction CWE Content Team MITRE 2008-09-08 updated Common_Consequences, Description, Relationships, Other_Notes, Taxonomy_Mappings CWE Content Team MITRE 2009-10-29 updated Description, Other_Notes, Potential_Mitigations CWE Content Team MITRE 2011-06-01 updated Common_Consequences, Relationships, Taxonomy_Mappings CWE Content Team MITRE 2012-05-11 updated Relationships, Taxonomy_Mappings CWE Content Team MITRE 2012-10-30 updated Demonstrative_Examples