Alternative data formats reduce deserialization risk
Switching from native deserialization formats to pure data formats like JSON or XML significantly reduces the risk of custom deserialization logic being repurposed for malicious ends.
OWASP Cheat Sheets · all subjects
deserialization
38 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
PHP unsafe deserialization function
The unserialize() function in PHP is unsafe for untrusted data. Use safe standard data interchange formats such as JSON via json_decode() and json_encode() instead.
Python pickle deserialization attack pattern
Python pickle, c_pickle, and _pickle modules with load or loads methods are vulnerable to deserialization attacks. Example vulnerable code: import pickle; data = """ cos.system(S'dir')tR. """; pickle.loads(data)
Python PyYAML unsafe load detection
PyYAML with the load method is vulnerable to deserialization attacks. Example: import yaml; document = "!!python/object/apply:os.system ['ipconfig']"; print(yaml.load(document))
Python jsonpickle deserialization vulnerability
jsonpickle encode or store methods are vulnerable to deserialization attacks when used with untrusted data.
Python serialization detection via dot symbol
If traffic data contains a dot '.' symbol at the end and is not Base64 or Hexadecimal encoded, it likely contains Python serialization. If Base64 encoded, check if data starts with 'gASV' which indicates serialization.
Java ObjectInputStream resolveClass override
Override ObjectInputStream#resolveClass() method to prevent arbitrary classes from being deserialized. This safe behavior can be wrapped in libraries like SerialKiller. The resolveClass method is called before readObject() is invoked, ensuring no deserialization occurs unless the type is allowed.
Java LookAheadObjectInputStream example implementation
Create a custom ObjectInputStream subclass that overrides resolveClass() to restrict allowed classes. Example: public class LookAheadObjectInputStream extends ObjectInputStream with @Override protected Class<?> resolveClass(ObjectStreamClass desc) that throws InvalidClassException for unauthorized class names.
Java vulnerable deserialization patterns
Search code for these vulnerable patterns: 1) XMLDecoder with external user defined parameters; 2) XStream with fromXML method (vulnerable in version <= v1.4.6); 3) ObjectInputStream with readObject; 4) readObject, readObjectNoData, readResolve, or readExternal methods; 5) ObjectInputStream.readUnshared; 6) Serializable interface implementation.
Java serialization stream detection patterns
Java serialization streams can be detected by: 1) Hex pattern AC ED 00 05; 2) Base64 pattern rO0; 3) HTTP Content-type header set to application/x-java-serialized-object
Java transient keyword for sensitive fields
Declare sensitive data members as 'private transient' to prevent them from being serialized or controlled during deserialization. For Serializable classes, use: private transient datatype fieldname;
Java prevent deserialization of domain objects
Prevent deserialization of application objects by declaring a final readObject() method that always throws an exception: private final void readObject(ObjectInputStream in) throws java.io.IOException { throw new java.io.IOException("Cannot be deserialized"); }
Java deserialization hardening with agent
Use Java agents to globally harden ObjectInputStream behavior without code changes. Enable by adding JVM parameter: -javaagent:name-of-agent.jar. rO0 by Contrast Security is an example agent that implements this approach. Only safe for block-listing known malicious types since expected classes vary by application.
fastjson2 safe configuration
fastjson2 (JSON) can be used safely with default configuration as long as the autotype option is not turned on.
jackson-databind safe configuration
jackson-databind (JSON) can be used safely with default configuration as long as polymorphism is not used.
Kryo v5.0.0+ safe configuration
Kryo v5.0.0 and later (custom format) can be used safely as long as class registration is not turned off. Earlier versions require class registration to be turned on for safety.
YamlBeans v1.16+ safe configuration
YamlBeans v1.16 and later (YAML) can be used safely as long as the UnsafeYamlConfig class is not used. Earlier versions allow deserialization of any class. A fork is available in Contrast-Security-OSS/yamlbeans for versions not available in Maven Central.
XStream safe configuration requirements
XStream v1.4.17 and later (JSON and XML) can be used safely as long as the allowlist and other security controls are not relaxed. Earlier versions (< v1.4.17) allow deserialization of any class and cannot be used safely.
fastjson v1.2.68+ requires safemode
fastjson v1.2.68 and later (JSON) cannot be used safely unless the safemode option is turned on, which disables deserialization of any class. Previous versions are not safe regardless of configuration.
json-io unsafe deserialization via @type property
json-io (JSON) cannot be used safely in typed mode because the @type property in JSON allows deserialization of any class. Safe usage: 1) Non-typed mode using JsonReader.USE_MAPS setting which disables generic object deserialization; 2) With a custom deserializer controlling which classes get deserialized.
Kryo < v5.0.0 requires class registration
Kryo versions earlier than v5.0.0 (custom format) cannot be used safely unless class registration is turned on, which disables deserialization of any class not registered. Note: wrappers around Kryo such as Chill may have different defaults regardless of underlying Kryo version.
SnakeYAML safe configuration requirement
SnakeYAML (YAML) cannot be used safely unless the org.yaml.snakeyaml.constructor.SafeConstructor class is used, which disables deserialization of any class.
Libraries that cannot be used safely with untrusted input
The following libraries cannot be used safely: 1) Castor (XML) - abandoned, no commits since 2016; 2) fastjson < v1.2.68 - allows deserialization of any class; 3) XMLDecoder in the JDK - described as 'close to impossible to securely deserialize Java objects from untrusted inputs'; 4) XStream < v1.4.17 - allows deserialization of any class; 5) YamlBeans < v1.16 - allows deserialization of any class.
.NET BinaryFormatter is dangerous
Microsoft has stated that the BinaryFormatter type is dangerous and cannot be secured. It should not be used. Full details are in the BinaryFormatter security guide.
.NET TypeNameHandling security configuration
Do not allow datastreams to define the object type that will be deserialized. Where JSON.Net is being used, ensure TypeNameHandling is set to None: TypeNameHandling = TypeNameHandling.None
.NET JavaScriptSerializer unsafe usage
If JavaScriptSerializer is used, do not use it with a JavaScriptTypeResolver as this allows arbitrary type instantiation during deserialization.
.NET recommended safe serializers
Use DataContractSerializer or XmlSerializer when possible to prevent type-defined deserialization, as they do not allow datastreams to define object types.
.NET FileInfo dangerous gadget
System.IO.FileInfo is a dangerous native .NET type. When deserialized with attacker-controlled properties, it can change properties of files on the server (e.g., read-only), creating a potential denial of service attack.
.NET ValidationException property type confusion
System.ComponentModel.DataAnnotations.ValidationException has a property Value of type Object. Even if this type is allowed for deserialization, an attacker can set the Value property to any object type they choose, bypassing type restrictions.
.NET unsafe code review patterns
Search .NET source code for: 1) TypeNameHandling; 2) JavaScriptTypeResolver. Look for any serializers where the type is set by a user controlled variable.
.NET unsafe opaque-box detection patterns
Search for .NET serialized data with: 1) Base64 encoded content starting with AAEAAAD/////; 2) Text containing TypeObject; 3) Text containing $type:
.NET RCE gadget types list
Known .NET RCE gadget types: System.Configuration.Install.AssemblyInstaller, System.Activities.Presentation.WorkflowDesigner, System.Windows.ResourceDictionary, System.Windows.Data.ObjectDataProvider, System.Windows.Forms.BindingSource, Microsoft.Exchange.Management.SystemManager.WinForms.ExchangeSettingsProvider, System.Data.DataViewManager, System.Xml.XmlDocument/XmlDataDocument, System.Management.Automation.PSObject
.NET deserialization timing vulnerability
Checking object type after deserialization is too late - execution may have already occurred during deserialization. Do not rely on post-deserialization type checks to prevent attacks.
.NET SerializationBinder custom control
For JSON.Net, create a safer form of allow-list control using a custom SerializationBinder to restrict which types can be deserialized.
.NET gadget chain isolation best practice
Keep any code that might create potential gadget classes separate from code that has internet connectivity. For example, do not reference System.Windows.Data.ObjectDataProvider (a known WPF gadget) in REST service projects that deserialize untrusted data.
.NET deserializer type knowledge limitation
A deserializer can only instantiate types that it knows about. An attacker cannot force deserialization of a type that is not available in the application's runtime.
Data transfer object pattern for safe deserialization
Use a data-transfer object pattern that creates a separate domain of objects explicitly for data transfer purposes. This reduces risk compared to deserializing directly to domain objects, though security mistakes can still occur after parsing.
Signed data deserialization strategy
Sign messages during serialization and only deserialize messages with authenticated signatures. This ensures the application only processes messages that are known to be safe.