Skip to content

Latest commit

 

History

History
99 lines (67 loc) · 4.69 KB

File metadata and controls

99 lines (67 loc) · 4.69 KB
title description ms.date author ms.author dev_langs f1_keywords
CA2352: Unsafe DataSet or DataTable in serializable type can be vulnerable to remote code execution attacks (code analysis)
Learn about code analysis rule CA2352: Unsafe DataSet or DataTable in serializable type can be vulnerable to remote code execution attacks
08/11/2020
dotpaul
paulming
CSharp
CA2352

CA2352: Unsafe DataSet or DataTable in serializable type can be vulnerable to remote code execution attacks

Property Value
Rule ID CA2352
Title Unsafe DataSet or DataTable in serializable type can be vulnerable to remote code execution attacks
Category Security
Fix is breaking or non-breaking Non-breaking
Enabled by default in .NET 8 No

Cause

A class or struct marked with xref:System.SerializableAttribute contains a xref:System.Data.DataSet or xref:System.Data.DataTable field or property, and doesn't have a xref:System.ComponentModel.DesignerCategoryAttribute.

CA2362 is a similar rule, for when there is a xref:System.ComponentModel.DesignerCategoryAttribute.

Rule description

When deserializing untrusted input with xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and the deserialized object graph contains a xref:System.Data.DataSet or xref:System.Data.DataTable, an attacker can craft a malicious payload to perform a remote code execution attack.

This rule finds types which are insecure when deserialized. If your code doesn't deserialize the types found, then you don't have a deserialization vulnerability.

For more information, see DataSet and DataTable security guidance.

How to fix violations

  • If possible, use Entity Framework rather than xref:System.Data.DataSet and xref:System.Data.DataTable.
  • Make the serialized data 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.

When to suppress warnings

It's safe to suppress a warning from this rule if:

  • The type found by this rule is never deserialized, either directly or indirectly.
  • You know the input is trusted. Consider that your application's trust boundary and data flows may change over time.
  • You've taken one of the precautions in How to fix violations.

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 CA2352
// The code that's violating the rule is on this line.
#pragma warning restore CA2352

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

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

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

Pseudo-code examples

Violation

using System.Data;
using System.Runtime.Serialization;

[Serializable]
public class MyClass
{
    public DataSet MyDataSet { get; set; }
}

Related rules

CA2350: Ensure DataTable.ReadXml()'s input is trusted

CA2351: Ensure DataSet.ReadXml()'s input is trusted

CA2353: Unsafe DataSet or DataTable in serializable type

CA2354: Unsafe DataSet or DataTable in deserialized object graph can be vulnerable to remote code execution attack

CA2355: Unsafe DataSet or DataTable in deserialized object graph

CA2356: Unsafe DataSet or DataTable in web deserialized object graph

CA2361: Ensure autogenerated class containing DataSet.ReadXml() is not used with untrusted data

CA2362: Unsafe DataSet or DataTable in autogenerated serializable type can be vulnerable to remote code execution attacks