CA5360: Do not call dangerous methods in deserialization

Article
04/22/2023

Property	Value
Rule ID	CA5360
Title	Do not call dangerous methods in deserialization
Category	Security
Fix is breaking or non-breaking	Non-breaking
Enabled by default in .NET 9	No

Cause

Calling one of the following dangerous methods in deserialization:

All methods meets one of the following requirements could be the callback of deserialization:

Marked with System.Runtime.Serialization.OnDeserializingAttribute.
Marked with System.Runtime.Serialization.OnDeserializedAttribute.
Implementing System.Runtime.Serialization.IDeserializationCallback.OnDeserialization.
Implementing System.IDisposable.Dispose.
Is a destructor.

Rule description

Insecure deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application, inflict a Denial-of-Service (DoS) attack, or even execute arbitrary code upon it being deserialized. It's frequently possible for malicious users to abuse these deserialization features when the application is deserializing untrusted data which is under their control. Specifically, invoke dangerous methods in the process of deserialization. Successful insecure deserialization attacks could allow an attacker to carry out attacks such as DoS attacks, authentication bypasses, and remote code execution.

How to fix violations

Remove these dangerous methods from automatically run deserialization callbacks. Call dangerous methods only after validating the input.

When to suppress warnings

It's safe to suppress this rule if:

You know the input is trusted. Consider that your application's trust boundary and data flows may change over time.
The serialized data is tamper-proof. After serialization, cryptographically sign the serialized data. Before deserialization, validate the cryptographic signature. Protect the cryptographic key from being disclosed and design for key rotations.
The data is validated as safe to the application.

Suppress a warning

If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.

#pragma warning disable CA5360
// The code that's violating the rule is on this line.
#pragma warning restore CA5360

To disable the rule for a file, folder, or project, set its severity to none in the configuration file.

[*.{cs,vb}]
dotnet_diagnostic.CA5360.severity = none

For more information, see How to suppress code analysis warnings.

Pseudo-code examples

Violation

using System;
using System.IO;
using System.Runtime.Serialization;

[Serializable()]
public class ExampleClass : IDeserializationCallback
{
    private string member;

    void IDeserializationCallback.OnDeserialization(Object sender)
    {
        var sourceFileName = "malicious file";
        var destFileName = "sensitive file";
        File.Copy(sourceFileName, destFileName);
    }
}

Solution

using System;
using System.IO;
using System.Runtime.Serialization;

[Serializable()]
public class ExampleClass : IDeserializationCallback
{
    private string member;

    void IDeserializationCallback.OnDeserialization(Object sender)
    {
        var sourceFileName = "malicious file";
        var destFileName = "sensitive file";
        // Remove the potential dangerous operation.
        // File.Copy(sourceFileName, destFileName);
    }
}

Share via