この記事は以下に適用されます。
- .NET Framework (すべてのバージョン)
- .NET Core 以降
- .NET 5 以降
DataSet 型と DataTable 型は .NET のレガシ コンポーネントであり、マネージド オブジェクトとしてデータ セットを表すことができます。 それらの目標は、リレーショナル データ セットに対するマネージド ビューを提供し、基になるデータのソースが XML、SQL、または他のテクノロジであるかどうかを抽象化することでした。
最新のデータ ビュー パラダイムを含め、ADO.NET の詳細については、ADO.NET のドキュメントを参照してください。
XML から DataSet または DataTable を逆シリアル化するときの既定の制限
.NET Framework、.NET Core、.NET のサポートされているすべてのバージョンで、DataSet と DataTable には、逆シリアル化されるデータに存在できるオブジェクトの型に関して次の制限があります。 既定では、このリストは以下に制限されます。
- プリミティブとプリミティブに相当するもの:
bool、char、sbyte、byte、short、ushort、int、uint、long、ulong、float、double、decimal、DateTime、DateTimeOffset、TimeSpan、string、Guid、SqlBinary、SqlBoolean、SqlByte、SqlBytes、SqlChars、SqlDateTime、SqlDecimal、SqlDouble、SqlGuid、SqlInt16、SqlInt32、SqlInt64、SqlMoney、SqlSingle、SqlString。 - 一般に使用される非プリミティブ:
Type、Uri、BigInteger。 - 一般に使用される System.Drawing 型:
Color、Point、PointF、Rectangle、RectangleF、Size、SizeF。 -
Enum型。 - 上記の型の配列およびリスト。
受信 XML データに、このリストにない型のオブジェクトが含まれている場合:
例外が、次のメッセージおよびスタック トレースでスローされます。 エラー メッセージ: System.InvalidOperationException : Type '<Type Name>, Version=<n.n.n.n>, Culture=<culture>, PublicKeyToken=<token value>' is not allowed here. (Type '
、Version= 、Culture= 、PublicKeyToken= ' は、ここでは許可されません。) スタックトレース: at System.Data.TypeLimiter.EnsureTypeIsAllowed(Type type, TypeLimiter capturedLimiter) at System.Data.DataColumn.UpdateColumnType(Type type, StorageType typeCode) at System.Data.DataColumn.set_DataType(Type value) 逆シリアル化操作が失敗する。
既存の DataSet または DataTable インスタンスに XML を読み込むときは、既存の列の定義も考慮されます。 テーブルにカスタム型の列定義が既に含まれている場合は、XML の逆シリアル化操作の間だけ、その型が許可リストに一時的に追加されます。
注
列を DataTable に追加すると、ReadXml は XML からスキーマを読み取らず、スキーマが一致しない場合は、レコードも読み取りません。そのため、このメソッドを使用するには、すべての列を手動で追加する必要があります。
XmlReader xmlReader = GetXmlReader();
// Assume the XML blob contains data for type MyCustomClass.
// The following call to ReadXml fails because MyCustomClass isn't in the allowed types list.
DataTable table = new DataTable("MyDataTable");
table.ReadXml(xmlReader);
// However, the following call to ReadXml succeeds, since the DataTable instance
// already defines a column of type MyCustomClass.
DataTable table = new DataTable("MyDataTable");
table.Columns.Add("MyColumn", typeof(MyCustomClass));
table.ReadXml(xmlReader); // this call will succeed
オブジェクトの型の制限は、XmlSerializer を使用して DataSet または DataTable のインスタンスを逆シリアル化するときにも適用されます。 ただし、BinaryFormatter を使用して DataSet または DataTable のインスタンスを逆シリアル化するときは、適用されない場合があります。
XML の逆シリアル化 API を使用せずにデータベースから直接 DataAdapter.Fill のインスタンスにデータを設定する場合など、DataTable を使用するときは、オブジェクトの型の制限は適用されません。
許可される型のリストを拡張する
アプリでは、許可される型のリストを拡張して、上記の組み込み型に加えてカスタム型を含めることができます。 許可される型のリストを拡張する場合、その変更は、アプリ内の "すべての" DataSet および DataTable のインスタンスに影響します。 組み込みの許可される型のリストから、型を削除することはできません。
構成を使用して拡張する (.NET Framework 4.0 以降)
App.config を使用して、許可される型のリストを拡張できます。 許可される型のリストを拡張するには、次のようにします。
-
<configSections>要素を使用して、System.Data 構成セクションへの参照を追加します。 -
<system.data.dataset.serialization>/<allowedTypes>を使用して、追加の型を指定します。
各 <add> 要素では、アセンブリ修飾型名を使用して、型を 1 つだけ指定する必要があります。 許可される型のリストに型を追加するには、複数の <add> 要素を使用します。
次の例では、カスタム型 Fabrikam.CustomType を追加することによって、許可される型のリストを拡張する方法を示します。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="system.data.dataset.serialization" type="System.Data.SerializationSettingsSectionGroup, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="allowedTypes" type="System.Data.AllowedTypesSectionHandler, System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</sectionGroup>
</configSections>
<system.data.dataset.serialization>
<allowedTypes>
<!-- <add type="assembly qualified type name" /> -->
<add type="Fabrikam.CustomType, Fabrikam, Version=1.0.0.0, Culture=neutral, PublicKeyToken=2b3831f2f2b744f7" />
<!-- additional <add /> elements as needed -->
</allowedTypes>
</system.data.dataset.serialization>
</configuration>
型のアセンブリ修飾名を取得するには、次のコードで示すように、Type.AssemblyQualifiedName プロパティを使用します。
string assemblyQualifiedName = typeof(Fabrikam.CustomType).AssemblyQualifiedName;
構成によって拡張する (.NET Framework 2.0 - 3.5)
アプリの対象が .NET Framework 2.0 または 3.5 の場合でも、上記の App.config のメカニズムを使用して、許可される型のリストを拡張できます。 ただし、次のコードで示すように、<configSections> 要素は少し異なります。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<!-- The below <sectionGroup> and <section> are specific to .NET Framework 2.0 and 3.5. -->
<sectionGroup name="system.data.dataset.serialization" type="System.Data.SerializationSettingsSectionGroup, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="allowedTypes" type="System.Data.AllowedTypesSectionHandler, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</sectionGroup>
</configSections>
<system.data.dataset.serialization>
<allowedTypes>
<!-- <add /> elements, as demonstrated in the .NET Framework 4.0 - 4.8 sample code above. -->
</allowedTypes>
</system.data.dataset.serialization>
</configuration>
プログラムによる拡張 (.NET Framework、.NET Core、.NET 5 以降)
許可される型のリストは、次のコードで示すように、AppDomain.SetData と既知のキー System.Data.DataSetDefaultAllowedTypes を使用することにより、プログラムで拡張することもできます。
Type[] extraAllowedTypes = new Type[]
{
typeof(Fabrikam.CustomType),
typeof(Contoso.AdditionalCustomType)
};
AppDomain.CurrentDomain.SetData("System.Data.DataSetDefaultAllowedTypes", extraAllowedTypes);
拡張メカニズムを使用している場合、キー System.Data.DataSetDefaultAllowedTypes に関連付ける値は、Type[] 型である必要があります。
.NET Framework では、App.config と AppDomain.SetData の両方で、許可される型のリストを拡張できます。 この場合、DataSet と DataTable では、その型がいずれかのリストに存在する場合、データの一部としてオブジェクトを逆シリアル化できます。
監査モードでアプリを実行する (.NET Framework)
.NET Framework では、DataSet と DataTable において監査モード機能が提供されます。 監査モードが有効になっていると、DataSet と DataTable では、受信したオブジェクトの型が、許可される型のリストと比較されます。 ただし、許可されていない型のオブジェクトが見つかった場合でも、例外はスローされません。 代わりに、DataSet と DataTable では、アタッチされている TraceListener のインスタンスに、疑わしい型が存在することが通知されます。これにより、TraceListener ではこの情報をログに記録できます。 例外はスローされず、逆シリアル化操作は続行されます。
警告
"監査モード" でのアプリの実行は、テストに使用する一時的な手段のみにする必要があります。 監査モードが有効になっていると、DataSet と DataTable では型の制限が適用されず、これによりアプリ内にセキュリティ ホールが生じる可能性があります。 詳細については、「すべての型の制限を削除する」および「信頼されていない入力に関する安全性」のセクションを参照してください。
監査モードは、App.config を使用して有効にすることができます。
-
要素に設定する適切な値については、このドキュメントの
<configSections>に関するセクションを参照してください。 - 次のマークアップで示すように、監査モードを有効にするには
<allowedTypes auditOnly="true">を使用します。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<!-- See the section of this document titled "Extending through configuration" for the appropriate
<sectionGroup> and <section> elements to put here, depending on whether you're running .NET
Framework 2.0 - 3.5 or 4.0 - 4.8. -->
</configSections>
<system.data.dataset.serialization>
<allowedTypes auditOnly="true"> <!-- setting auditOnly="true" enables audit mode -->
<!-- Optional <add /> elements as needed. -->
</allowedTypes>
</system.data.dataset.serialization>
</configuration>
監査モードを有効にした後は、App.config を使用して、適切な TraceListener を DataSet の組み込みの TraceSource. に接続できます。組み込みのトレース ソースの名前は System.Data.DataSet です。 次の例では、トレース イベントをコンソールとディスク上のログ ファイルに書き込む方法を示します。
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.diagnostics>
<sources>
<source name="System.Data.DataSet"
switchType="System.Diagnostics.SourceSwitch"
switchValue="Warning">
<listeners>
<!-- write to the console -->
<add name="console"
type="System.Diagnostics.ConsoleTraceListener" />
<!-- *and* write to a log file on disk -->
<add name="filelog"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="c:\logs\mylog.txt" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
TraceSource と TraceListener の詳細については、「方法: TraceSource とフィルターをトレース リスナーと共に使用する」を参照してください。
注
監査モードでのアプリの実行は、.NET Core または .NET 5 以降ではできません。
すべての型の制限を削除する
アプリで DataSet と DataTable からすべての型の制限を削除する必要がある場合:
- 型の制限を抑制するには、いくつかのオプションがあります。
- 使用できるオプションは、アプリの対象となるフレームワークによって異なります。
警告
型の制限をすべて削除すると、アプリ内にセキュリティ ホールが生じる可能性があります。 このメカニズムを使用するときは、アプリで信頼されていない入力を読み取るために 使用しないようにし、DataSet または DataTable を使わないことを確認してください。 詳細については、CVE-2020-1147 および後のセクション「信頼されていない入力に関する安全性」を参照してください。
AppContext の構成を使用 (.NET Framework 4.6 以降、.NET Core 2.1 以降、.NET 5 以降)
AppContext スイッチの Switch.System.Data.AllowArbitraryDataSetTypeInstantiation を true に設定すると、DataSet および DataTable からすべての型制限が削除されます。
.NET Framework では、次の構成で示すように、App.config を使用してこのスイッチを有効にすることができます。
<configuration>
<runtime>
<!-- Warning: setting the following switch can introduce a security problem. -->
<AppContextSwitchOverrides value="Switch.System.Data.AllowArbitraryDataSetTypeInstantiation=true" />
</runtime>
</configuration>
ASP.NET では、<AppContextSwitchOverrides> 要素は使用できません。 代わりに、次の構成で示すように、Web.config を使用してスイッチを有効にすることができます。
<configuration>
<appSettings>
<!-- Warning: setting the following switch can introduce a security problem. -->
<add key="AppContext.SetSwitch:Switch.System.Data.AllowArbitraryDataSetTypeInstantiation" value="true" />
</appSettings>
</configuration>
詳細については、「<AppContextSwitchOverrides> 要素」を参照してください。
.NET Core、.NET 5、および ASP.NET Core では、次の JSON で示すように、この設定は runtimeconfig.json によって制御されます。
{
"runtimeOptions": {
"configProperties": {
"Switch.System.Data.AllowArbitraryDataSetTypeInstantiation": true
}
}
}
詳細については、「.NET Core ランタイム構成設定」を参照してください。
AllowArbitraryDataSetTypeInstantiation は、構成ファイルを使用する代わりに、次のコードで示すように、AppContext.SetSwitch を使用してプログラムで設定することもできます。
// Warning: setting the following switch can introduce a security problem.
AppContext.SetSwitch("Switch.System.Data.AllowArbitraryDataSetTypeInstantiation", true);
前述のプログラムによる方法を選択する場合は、アプリの起動の初期段階で AppContext.SetSwitch の呼び出しを行う必要があります。
コンピューター全体のレジストリを使用 (.NET Framework 2.0 から 4.x)
AppContext を使用できない場合は、Windows レジストリを使用して、型制限のチェックを無効にすることができます。
- 管理者は、レジストリを構成する必要があります。
- レジストリの使用は、コンピューター全体の変更であり、コンピューター上で実行されている "すべての" アプリに影響を与えます。
| タイプ | [値] |
|---|---|
| レジストリ キー | HKLM\SOFTWARE\Microsoft\.NETFramework\AppContext |
| 値の名前 | Switch.System.Data.AllowArbitraryDataSetTypeInstantiation |
| 値の型 | REG_SZ |
| データの値 | true |
64 ビットのオペレーティング システムでは、64 ビット キー (上記) と 32 ビット キーの両方に、この値を追加することが必要な場合があります。 32 ビット キーは HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\AppContext にあります。
レジストリを使用して AppContext を構成する方法の詳細については、「ライブラリ コンシューマーの AppContext」を参照してください。
信頼されていない入力に関する安全性
DataSet と DataTable では、XML ペイロードの逆シリアル化中に存在することが許可される型に対して既定の制限が適用されますが、DataSet と DataTable は、信頼されていない入力で設定されるときは一般に安全ではありません。次に示すのは、DataSet または DataTable のインスタンスが信頼されていない入力を読み取る可能性がある方法の一覧ですが、これだけではありません。
-
DataAdapterでデータベースを参照し、DataAdapter.Fillメソッドを使用してデータベース クエリの内容をDataSetに設定します。 -
DataSet.ReadXmlまたはDataTable.ReadXmlメソッドを使用して、列と行の情報が含まれる XML ファイルを読み取ります。 - ASP.NET (SOAP) Web サービスまたは WCF エンドポイントの一部として、
DataSetまたはDataTableのインスタンスをシリアル化します。 -
XmlSerializerなどのシリアライザーを使用して、XML ストリームからDataSetまたはDataTableのインスタンスを逆シリアル化します。 -
JsonConvertなどのシリアライザーを使用して、JSON ストリームからDataSetまたはDataTableのインスタンスを逆シリアル化します。JsonConvertは、一般的なサードパーティの Newtonsoft.Json ライブラリのメソッドです。 -
BinaryFormatterなどのシリアライザーを使用して、RAW 型バイト ストリームからDataSetまたはDataTableのインスタンスを逆シリアル化します。
このドキュメントでは、前述のシナリオの安全性に関する考慮事項について説明します。
DataAdapter.Fill を使用して、信頼されていないデータ ソースから DataSet を設定する
次の例に示すように、DataSet メソッドを使用して DataAdapter から DataAdapter.Fill インスタンスを生成できます。
// Assumes that connection is a valid SqlConnection object.
string queryString =
"SELECT CustomerID, CompanyName FROM dbo.Customers";
SqlDataAdapter adapter = new SqlDataAdapter(queryString, connection);
DataSet customers = new DataSet();
adapter.Fill(customers, "Customers");
(上のコード例は、「DataAdapter からの DataSet の読み込み」にある、より大きな例の一部です。)
ほとんどのアプリでは単純化し、データベース レイヤーが信頼されていると想定できます。 ただし、アプリの脅威モデリングを行う習慣がある場合は、脅威モデルで、アプリケーション (クライアント) とデータベース層 (サーバー) の間に信頼境界があると考えられる場合があります。 クライアントとサーバーの間で相互認証または AAD 認証を使用することは、これに関連するリスクに対処するための 1 つの方法です。 このセクションの残りの部分では、信頼されていないサーバーに接続するクライアントで可能性のある結果について説明します。
信頼されていないデータ ソースで DataAdapter を参照した場合の結果は、DataAdapter 自体の実装によって異なります。
SqlDataAdapter
組み込み型 SqlDataAdapter の場合、信頼されていないデータ ソースを参照すると、サービス拒否 (DoS) 攻撃が発生する可能性があります。 DoS 攻撃により、アプリが応答しなくなったりクラッシュしたりする可能性があります。 攻撃者がアプリと一緒に DLL を仕掛けることができる場合は、ローカル コード実行も実現できる可能性があります。
その他の DataAdapter タイプ
サードパーティによる DataAdapter の実装では、信頼されていない入力に対して提供するセキュリティ保証について、独自の評価を行う必要があります。 .NET では、これらの実装に関する安全性についてどのような保証も行うことはできません。
DataSet.ReadXml と DataTable.ReadXml
DataSet.ReadXml メソッドと DataTable.ReadXml メソッドは、信頼されていない入力で使用するときは安全ではありません。 代わりにこのドキュメントで後述する代替手段のいずれかの使用を検討することを強くお勧めします。
DataSet.ReadXml と DataTable.ReadXml の実装は、もともと、シリアル化の脆弱性がよく理解された脅威カテゴリになる前に作成されました。 このため、そのコードは現在のセキュリティのベスト プラクティスに従っていません。 これらの API は、攻撃者が Web アプリに対して DoS 攻撃を実行するためのベクトルとして使用できます。 これらの攻撃によって、Web サービスが応答しなくなったり、予期しないプロセスの終了が発生したりする可能性があります。 フレームワークでは、これらの攻撃カテゴリに対する軽減策が提供されず、.NET ではこの動作は "仕様" と見なされます。
.NET では、DataSet.ReadXml および DataTable.ReadXml での情報漏えいやリモート コード実行などの一部の問題を軽減するために、セキュリティ更新プログラムがリリースされています。 .NET のセキュリティ更新プログラムでは、これらの脅威カテゴリに対する完全な保護が提供されない場合があります。 コンシューマーは、個々のシナリオを評価し、これらのリスクに対する潜在的な危険を検討する必要があります。
コンシューマーは、これらの API に対するセキュリティ更新プログラムが、アプリケーションの互換性に影響する場合があることに注意する必要があります。 さらに、これらの API には .NET でセキュリティ更新プログラムを実質的に公開できない新しい脆弱性が検出される可能性があります。
これらの API のコンシューマーには、次のいずれかをお勧めします。
- 後で説明するいずれかの代替手段を使用することを検討します。
- アプリで個々のリスク評価を実行します。
これらの API を利用するかどうかの判断に関する責任は、すべてコンシューマーにあります。 コンシューマーは、これらの API の使用に伴う可能性のある、規制要件を含む、セキュリティ、技術的、および法的リスクを評価する必要があります。
ASP.NET Web サービスまたは WCF による DataSet と DataTable
次のコードで示すように、ASP.NET (SOAP) Web サービスで DataSet または DataTable のインスタンスを受け入れることができます。
using System.Data;
using System.Web.Services;
[WebService(Namespace = "http://contoso.com/")]
public class MyService : WebService
{
[WebMethod]
public string MyWebMethod(DataTable dataTable)
{
/* Web method implementation. */
}
}
これのバリエーションとしては、DataSet または DataTable をパラメーターとして直接受け入れるのではなく、次のコードで示すように、SOAP でシリアル化されたオブジェクト グラフ全体の一部として受け入れます。
using System.Data;
using System.Web.Services;
[WebService(Namespace = "http://contoso.com/")]
public class MyService : WebService
{
[WebMethod]
public string MyWebMethod(MyClass data)
{
/* Web method implementation. */
}
}
public class MyClass
{
// Property of type DataTable, automatically serialized and
// deserialized as part of the overall MyClass payload.
public DataTable MyDataTable { get; set; }
}
または、ASP.NET Web サービスの代わりに WCF を使用します。
using System.Data;
using System.ServiceModel;
[ServiceContract(Namespace = "http://contoso.com/")]
public interface IMyContract
{
[OperationContract]
string MyMethod(DataTable dataTable);
[OperationContract]
string MyOtherMethod(MyClass data);
}
public class MyClass
{
// Property of type DataTable, automatically serialized and
// deserialized as part of the overall MyClass payload.
public DataTable MyDataTable { get; set; }
}
これらのどのケースでも、脅威モデルとセキュリティの保証は「DataSet.ReadXml と DataTable.ReadXml section」セクションと同じです。
XmlSerializer を使用して DataSet または DataTable を逆シリアル化する
開発者は、次のコードで示すように、XmlSerializer を使用して DataSet や DataTable のインスタンスを逆シリアル化できます。
using System.Data;
using System.IO;
using System.Xml.Serialization;
public DataSet PerformDeserialization1(Stream stream) {
XmlSerializer serializer = new XmlSerializer(typeof(DataSet));
return (DataSet)serializer.Deserialize(stream);
}
public MyClass PerformDeserialization2(Stream stream) {
XmlSerializer serializer = new XmlSerializer(typeof(MyClass));
return (MyClass)serializer.Deserialize(stream);
}
public class MyClass
{
// Property of type DataTable, automatically serialized and
// deserialized as part of the overall MyClass payload.
public DataTable MyDataTable { get; set; }
}
このような場合、脅威モデルとセキュリティの保証は、DataSet.ReadXml および DataTable.ReadXml セクションと同じです。
JsonConvert を使用して DataSet または DataTable を逆シリアル化する
次のコードに示すように、サードパーティの Newtonsoft ライブラリ Json.NET を使用して、DataSet インスタンスと DataTable インスタンスを逆シリアル化できます。
using System.Data;
using Newtonsoft.Json;
public DataSet PerformDeserialization1(string json) {
return JsonConvert.DeserializeObject<DataSet>(data);
}
public MyClass PerformDeserialization2(string json) {
return JsonConvert.DeserializeObject<MyClass>(data);
}
public class MyClass
{
// Property of type DataTable, automatically serialized and
// deserialized as part of the overall MyClass payload.
public DataTable MyDataTable { get; set; }
}
この方法で信頼されていない JSON BLOB から DataSet または DataTable を逆シリアル化することは、安全ではありません。 このパターンは、サービス拒否攻撃に対して脆弱です。 このような攻撃によって、アプリがクラッシュしたり、応答しなくなったりする可能性があります。
注
Microsoft では、Newtonsoft.Json のようなサードパーティ製ライブラリの実装については、保証もサポートも行いません。 この情報は完全を期すために提供されており、このドキュメントの執筆時点の正確な情報です。
BinaryFormatter を使用して DataSet または DataTable を逆シリアル化する
BinaryFormatter、NetDataContractSerializer、SoapFormatter、または関連する "安全でない" フォーマッタを使用して、信頼されていないペイロードから DataSet または DataTable のインスタンスを逆シリアル化しないでください。
- これは、完全なリモート コード実行攻撃の影響を受けやすくなります。
- このような攻撃を防ぐには、カスタム
SerializationBinderを使用するだけでは不十分です。
安全な置換
次のいずれかのアプリの場合:
- .asmx SOAP エンドポイントまたは WCF エンドポイントを通して
DataSetまたはDataTableを受け入れる。 - 信頼されていないデータを
DataSetまたはDataTableのインスタンスに逆シリアル化する。
Entity Framework を使用するようにオブジェクト モデルを置き換えることを検討してください。 エンティティ フレームワーク:
- リレーショナル データを表すことができる、高度な最新のオブジェクト指向フレームワークです。
- 多様なエコシステムのデータベース プロバイダーを使用して、Entity Framework オブジェクト モデルを通じてデータベース クエリを簡単にマッピングできます。
- 信頼されていないソースからデータを逆シリアル化するときに、組み込みの保護が提供されます。
.aspx SOAP エンドポイントを使用するアプリの場合、WCF を使用するようにそれらのエンドポイントを変更することを検討してください。 WCF は、.asmx Web サービスに対する、より完全な機能を備えた代替手段です。 既存の呼び出し元との互換性のため、WCF エンドポイントは SOAP 経由で公開できます。
コード アナライザー
自分のソース コードをコンパイルするときに実行されるコード アナライザーのセキュリティ規則は、C# および Visual Basic コードで、このセキュリティの問題に関連する脆弱性を検出するのに役立ちます。 Microsoft.CodeAnalysis.FxCopAnalyzers は、nuget.org で配布されるコード アナライザーの NuGet パッケージです。
コード アナライザーの概要については、「ソース コード アナライザーの概要」を参照してください。
次の Microsoft.CodeAnalysis.FxCopAnalyzers 規則を有効にします。
- CA2350:信頼されていないデータで DataTable.ReadXml() を使用しない
- CA2351:信頼されていないデータで DataSet.ReadXml() を使用しない
- CA2352:シリアル化可能な型の安全でない DataSet または DataTable は、リモート コード実行攻撃に対して脆弱になる可能性があります
- CA2353: シリアル化可能な型の安全でない DataSet や DataTable
- CA2354:逆シリアル化されたオブジェクト グラフの安全でない DataSet または DataTable が、リモート コード実行攻撃に対して脆弱になる可能性があります
- CA2355:逆シリアル化可能なオブジェクト グラフに、安全でない DataSet または DataTable 型が見つかりました
- CA2356:Web の逆シリアル化可能なオブジェクト グラフに含まれる安全でない DataSet または DataTable 型
- CA2361:DataSet.ReadXml() を含む自動生成クラスが信頼されていないデータで使用されていないことを確認してください
- CA2362:シリアル化可能な自動生成型の安全でない DataSet または DataTable は、リモート コード実行攻撃に対して脆弱になる可能性があります
ルールの構成の詳細については、「コード アナライザーを使用する」を参照してください。
この新しいルールは、次の NuGet パッケージで入手できます。
- Microsoft.CodeAnalysis.FxCopAnalyzers 3.3.0: Visual Studio 2019 バージョン 16.3 以降向け
- Microsoft.CodeAnalysis.FxCopAnalyzers 2.9.11: Visual Studio 2017 バージョン 15.9 以降向け