CA5360: Do not call dangerous methods in deserialization
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:
- System.IO.Directory.Delete
- System.IO.DirectoryInfo.Delete
- System.IO.File.AppendAllLines
- System.IO.File.AppendAllText
- System.IO.File.AppendText
- System.IO.File.Copy
- System.IO.File.Delete
- System.IO.File.WriteAllBytes
- System.IO.File.WriteAllLines
- System.IO.File.WriteAllText
- System.IO.FileInfo.Delete
- System.IO.Log.LogStore.Delete
- System.Reflection.Assembly.GetLoadedModules
- System.Reflection.Assembly.Load
- System.Reflection.Assembly.LoadFrom
- System.Reflection.Assembly.LoadFile
- System.Reflection.Assembly.LoadModule
- System.Reflection.Assembly.LoadWithPartialName
- System.Reflection.Assembly.ReflectionOnlyLoad
- System.Reflection.Assembly.ReflectionOnlyLoadFrom
- System.Reflection.Assembly.UnsafeLoadFrom
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);
}
}