Is Your Json.Net `TypeNameHandling` Setting (Auto) Vulnerable to External JSON Data Attacks?

Can External JSON Data Pose a Threat with Json.Net TypeNameHandling Set to Auto?

In JSON deserialization, the TypeNameHandling setting of Json.Net plays a crucial role in mitigating potential threats. However, concerns remain regarding the safety of using this setting with user-provided JSON data. Let's delve into the issue and explore the potential risks and precautions.

The Vulnerabilities of TypeNameHandling

External JSON payloads can be manipulated to contain "$type" properties that specify types for deserialization. If these types are not carefully validated, attackers can exploit them to instantiate rogue objects known as "attack gadgets." These gadgets can execute malicious actions, such as remote code execution (RCE) or file system manipulation.

Protection Measures

Json.Net has implemented safeguards to prevent such attacks:

• Unknown Property Ignorance: It ignores unknown properties, rendering JSON payloads with extraneous "$type" properties harmless.
• Serialization Compatibility: During polymorphic value deserialization, it checks whether the resolved type matches the expected one. If not, an exception is thrown.

Potential Loopholes

Despite these measures, there are certain situations where an attack gadget might still be constructed, even in the absence of obvious untyped members:

• Untyped Collections: Deserializing collections of unknown types, such as ArrayList, List
• Semi-Typed Collections: Deserializing collections derived from CollectionBase, which support runtime type validation, can create a window for gadget construction.
• Shared Base Types: Polymorphic members declared as interfaces or base types shared by attack gadgets (e.g., ICollection, IDisposable) can introduce vulnerabilities.
• ISerializable Interface: Types implementing ISerializable may unintentionally deserialize untyped members, exposing them to attack.
• Conditional Serialization: Members marked as non-serialized in ShouldSerializeAttribute may still be deserialized if present in the JSON payload.

Recommendations

To minimize risks, consider the following recommendations:

• Validate Unknown Types: Implement a custom SerializationBinder to check incoming serialized types and reject unauthorized ones.
• Avoid Untyped Members: Ensure that your data model doesn't contain members of type object, dynamic, or other potentially exploitable types.
• Set DefaultContractResolver: Consider setting DefaultContractResolver.IgnoreSerializableInterface and DefaultContractResolver.IgnoreSerializableAttribute to true.
• Review Code for Non-Serialized Members: Verify that members marked as non-serialized are not deserialized in unexpected situations.

By adhering to these best practices, you can greatly reduce the likelihood of external JSON data compromising your system through Json.Net TypeNameHandling set to Auto.

The above is the detailed content of Is Your Json.Net `TypeNameHandling` Setting (Auto) Vulnerable to External JSON Data Attacks?. For more information, please follow other related articles on the PHP Chinese website!