Share via

Diretrizes de segurança DataSet e DataTable

  • Artigo

Este artigo aplica-se a:

  • .NET Framework (todas as versões)
  • .NET Core e posterior
  • .NET 5 e posterior

Os tipos DataSet e DataTable são componentes .NET herdados que permitem representar conjuntos de dados como objetos gerenciados. Esses componentes foram introduzidos no .NET Framework 1.0 como parte da infraestrutura ADO.NET original. Seu objetivo era fornecer uma visão gerenciada sobre um conjunto de dados relacional, abstraindo se a fonte subjacente dos dados era XML, SQL ou outra tecnologia.

Para obter mais informações sobre ADO.NET, incluindo paradigmas de exibição de dados mais modernos, consulte a documentação ADO.NET.

Restrições padrão ao desserializar um DataSet ou DataTable de XML

Em todas as versões suportadas do .NET Framework, .NET Core e .NET, DataSet e DataTable coloque as seguintes restrições sobre os tipos de objetos que podem estar presentes nos dados desserializados. Por padrão, essa lista é restrita a:

  • Primitivos e equivalentes primitivos: , , , , byteshort, SqlInt32TimeSpanSqlMoneyDateTimeOffsetSqlSingleSqlInt16SqlDoubleSqlDecimalSqlCharsSqlByteSqlBinaryGuiddoubleulongSqlInt64SqlGuidSqlBytesSqlBooleanDateTimedecimalstringuintfloatSqlDateTimelongushortinte .SqlStringsbytecharbool
  • Não primitivos comumente usados: Type, Uri, e BigInteger.
  • Tipos de System.Drawing comumente usados: Color, Point, PointF, Rectangle, RectangleF, Sizee SizeF.
  • Enum tipos.
  • Matrizes e listas dos tipos acima.

Se os dados XML de entrada contiverem um objeto cujo tipo não esteja nesta lista:

  • Uma exceção é lançada com a seguinte mensagem e rastreamento de pilha. Mensagem de erro: System.InvalidOperationException : Tipo '<Type Name>, Version=<n.n.n.n>, Culture=<culture>, PublicKeyToken=<token value>' não é permitido aqui. Rastreamento de pilha: em System.Data.TypeLimiter.EnsureTypeIsAllowed(Type type, TypeLimiter capturedLimiter) em System.Data.DataColumn.UpdateColumnType(Type type, StorageType typeCode) em System.Data.DataColumn.set_DataType(Type value)

  • A operação de desserialização falha.

Ao carregar XML em uma instância ou DataTable existenteDataSet, as definições de coluna existentes também são levadas em consideração. Se a tabela já contiver uma definição de coluna de um tipo personalizado, esse tipo será adicionado temporariamente à lista de permissões durante a operação de desserialização XML.

Nota

Depois de adicionar colunas a um DataTable, ReadXml não lerá o esquema do XML e, se o esquema não corresponder, também não será lido nos registros, portanto, você precisará adicionar todas as colunas para usar esse método.

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

As restrições de tipo de objeto também se aplicam ao usar XmlSerializer para desserializar uma instância de DataSet ou DataTable. No entanto, eles podem não se aplicar ao usar BinaryFormatter para desserializar uma instância de DataSet ou DataTable.

As restrições de tipo de objeto não se aplicam ao usar DataAdapter.Fillo , como quando uma DataTable instância é preenchida diretamente de um banco de dados sem usar as APIs de desserialização XML.

Estender a lista de tipos permitidos

Um aplicativo pode estender a lista de tipos permitidos para incluir tipos personalizados, além dos tipos internos listados acima. Se estender a lista de tipos permitidos, a alteração afetará todas asDataSet instâncias dentro DataTable do aplicativo. Os tipos não podem ser removidos da lista interna de tipos permitidos.

Estender através da configuração (.NET Framework 4.0 e posterior)

App.config pode ser usado para estender a lista de tipos permitidos. Para estender a lista de tipos permitidos:

  • Use o <configSections> elemento para adicionar uma referência à seção de configuração System.Data .
  • Use <system.data.dataset.serialization>/<allowedTypes> para especificar tipos adicionais.

Cada <add> elemento deve especificar apenas um tipo usando seu nome de tipo qualificado de assembly. Para adicionar tipos adicionais à lista de tipos permitidos, use vários <add> elementos.

O exemplo a seguir mostra a extensão da lista de tipos permitidos adicionando o tipo Fabrikam.CustomTypepersonalizado .

<?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>

Para recuperar o nome qualificado do assembly de um tipo, use a propriedade Type.AssemblyQualifiedName , conforme demonstrado no código a seguir.

string assemblyQualifiedName = typeof(Fabrikam.CustomType).AssemblyQualifiedName;

Estender através da configuração (.NET Framework 2.0 - 3.5)

Se seu aplicativo tiver como destino o .NET Framework 2.0 ou 3.5, você ainda poderá usar o mecanismo App.config acima para estender a lista de tipos permitidos. No entanto, seu <configSections> elemento terá uma aparência ligeiramente diferente, conforme mostrado no código a seguir:

<?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>

Estender programaticamente (.NET Framework, .NET Core, .NET 5+)

A lista de tipos permitidos também pode ser estendida programaticamente usando AppDomain.SetData com a chave conhecida System.Data.DataSetDefaultAllowedTypes, conforme mostrado no código a seguir.

Type[] extraAllowedTypes = new Type[]
{
    typeof(Fabrikam.CustomType),
    typeof(Contoso.AdditionalCustomType)
};

AppDomain.CurrentDomain.SetData("System.Data.DataSetDefaultAllowedTypes", extraAllowedTypes);

Se estiver usando o mecanismo de extensão, o valor associado à chave System.Data.DataSetDefaultAllowedTypes deve ser do tipo Type[].

No .NET Framework, a lista de tipos permitidos pode ser estendida com App.config e AppDomain.SetData. Nesse caso, DataSet e DataTable permitirá que um objeto seja desserializado como parte dos dados se seu tipo estiver presente em qualquer lista.

Executar um aplicativo no modo de auditoria (.NET Framework)

No .NET Framework DataSet e DataTable fornecer um recurso de modo de auditoria. Quando o modo de auditoria estiver habilitado, DataSet compare DataTable os tipos de objetos de entrada com a lista de tipos permitidos. No entanto, se um objeto cujo tipo não é permitido for visto, uma exceção não será lançada. Em vez disso, DataSet e notifique DataTable todas as instâncias anexadas TraceListener de que um tipo suspeito está presente, permitindo que o TraceListener registre essas informações. Nenhuma exceção é lançada e a operação de desserialização continua.

Aviso

A execução de um aplicativo no "modo de auditoria" deve ser apenas uma medida temporária usada para testes. Quando o modo de auditoria estiver habilitado DataSet e DataTable não impor restrições de tipo, o que pode introduzir uma falha de segurança dentro do seu aplicativo. Para obter mais informações, consulte as seções intituladas Removendo todas as restrições de tipo e Segurança em relação a entradas não confiáveis.

O modo de auditoria pode ser ativado através do App.config:

  • Consulte a seção Estendendo através da configuração neste documento para obter informações sobre o valor adequado a ser colocado para o <configSections> elemento.
  • Use <allowedTypes auditOnly="true"> para habilitar o modo de auditoria, conforme mostrado na marcação a seguir.
<?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>

Depois que o modo de auditoria estiver habilitado, você poderá usar App.config para conectar sua DataSet preferência TraceListener ao interno TraceSource. O nome da fonte de rastreamento interna é System.Data.DataSet. O exemplo a seguir demonstra a gravação de eventos de rastreamento no console e em um arquivo de log no disco.

<?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>

Para obter mais informações sobre TraceSource e TraceListener, consulte o documento Como usar TraceSource e filtros com ouvintes de rastreamento.

Nota

A execução de um aplicativo no modo de auditoria não está disponível no .NET Core ou no .NET 5 e posterior.

Remover todas as restrições de tipo

Se um aplicativo precisar remover todas as restrições de limitação de tipo de DataSet e DataTable:

  • Existem várias opções para suprimir restrições limitadoras de tipo.
  • As opções disponíveis dependem da estrutura a que o aplicativo se destina.

Aviso

Remover todas as restrições de tipo pode introduzir uma falha de segurança dentro do aplicativo. Ao usar esse mecanismo, certifique-se de que o aplicativo não use DataSet ou DataTable leia entradas não confiáveis. Para obter mais informações, consulte CVE-2020-1147 e a seção a seguir intitulada Segurança em relação a entradas não confiáveis.

Através da configuração do AppContext (.NET Framework 4.6 e posterior, .NET Core 2.1 e posterior, .NET 5 e posterior)

O AppContext switch, Switch.System.Data.AllowArbitraryDataSetTypeInstantiation, quando definido para true remover todas as restrições de limitação de tipo de DataSet e DataTable.

No .NET Framework, essa opção pode ser habilitada via App.config, conforme mostrado na seguinte configuração:

<configuration>
   <runtime>
      <!-- Warning: setting the following switch can introduce a security problem. -->
      <AppContextSwitchOverrides value="Switch.System.Data.AllowArbitraryDataSetTypeInstantiation=true" />
   </runtime>
</configuration>

Em ASP.NET, o <AppContextSwitchOverrides> elemento não está disponível. Em vez disso, o switch pode ser ativado via Web.config, conforme mostrado na seguinte configuração:

<configuration>
    <appSettings>
        <!-- Warning: setting the following switch can introduce a security problem. -->
        <add key="AppContext.SetSwitch:Switch.System.Data.AllowArbitraryDataSetTypeInstantiation" value="true" />
    </appSettings>
</configuration>

Para obter mais informações, consulte o elemento AppContextSwitchOverrides>.<

No .NET Core, .NET 5 e ASP.NET Core, essa configuração é controlada por runtimeconfig.json, conforme mostrado no seguinte JSON:

{
  "runtimeOptions": {
    "configProperties": {
      "Switch.System.Data.AllowArbitraryDataSetTypeInstantiation": true
    }
  }
}

Para obter mais informações, consulte "Definições de configuração de tempo de execução do .NET Core".

AllowArbitraryDataSetTypeInstantiation também pode ser definido programaticamente via AppContext.SetSwitch em vez de usar um arquivo de configuração, como mostrado no código a seguir:

// Warning: setting the following switch can introduce a security problem.
AppContext.SetSwitch("Switch.System.Data.AllowArbitraryDataSetTypeInstantiation", true);

Se você escolher a abordagem programática anterior, a chamada para AppContext.SetSwitch deve ocorrer no início da inicialização dos aplicativos.

Através do registo em toda a máquina (.NET Framework 2.0 - 4.x)

Se AppContext não estiver disponível, as verificações de limitação de tipo podem ser desativadas com o registro do Windows:

  • Um administrador deve configurar o registro.
  • O uso do registro é uma alteração em toda a máquina e afetará todos os aplicativos em execução na máquina.
Type valor
Chave do registo HKLM\SOFTWARE\Microsoft\.NETFramework\AppContext
Nome do valor Switch.System.Data.AllowArbitraryDataSetTypeInstantiation
Tipo de valor REG_SZ
Dados de valor true

Em um sistema operacional de 64 bits, esse valor precisa ser adicionado tanto para a chave de 64 bits (mostrada acima) quanto para a chave de 32 bits. A chave de 32 bits está localizada em HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\AppContext.

Para obter mais informações sobre como usar o Registro para configurar AppContexto , consulte "AppContext for library consumers".

Segurança em relação a informações não confiáveis

Enquanto DataSet e DataTable impõem limitações padrão aos tipos que podem estar presentes durante a desserialização de cargas úteis XML eDataTable, em geral, DataSet não são seguros quando preenchidos com entrada não confiável. A seguir está uma lista não exaustiva de maneiras pelas quais uma DataSet instância ou DataTable instância pode ler entradas não confiáveis.

  • A DataAdapter faz referência a um banco de dados e o DataAdapter.Fill método é usado para preencher um DataSet com o conteúdo de uma consulta de banco de dados.
  • O DataSet.ReadXml método or DataTable.ReadXml é usado para ler um arquivo XML contendo informações de coluna e linha.
  • Uma DataSet instância ou DataTable é serializada como parte de um ASP.NET (SOAP) Web Services ou WCF endpoint.
  • Um serializador como XmlSerializer é usado para desserializar uma DataSet instância ou DataTable de um fluxo XML.
  • Um serializador como JsonConvert é usado para desserializar uma DataSet instância ou DataTable de um fluxo JSON. JsonConverté um método na popular biblioteca Newtonsoft.Json de terceiros.
  • Um serializador como BinaryFormatter é usado para desserializar uma DataSet instância ou DataTable de um fluxo de bytes brutos.

Este documento discute considerações de segurança para os cenários anteriores.

Usar DataAdapter.Fill para preencher um DataSet a partir de uma fonte de dados não confiável

Uma DataSet instância pode ser preenchida a partir de um DataAdapter usando o DataAdapter.Fill método, como mostrado no exemplo a seguir.

// 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");

(O exemplo de código acima faz parte de uma amostra maior encontrada em Preenchendo um DataSet de um DataAdapter.)

A maioria dos aplicativos pode simplificar e assumir que sua camada de banco de dados é confiável. No entanto, se você tiver o hábito de modelar ameaças em seus aplicativos, seu modelo de ameaça pode considerar que há um limite de confiança entre o aplicativo (cliente) e a camada de banco de dados (servidor). Usar a autenticação mútua ou a autenticação AAD entre cliente e servidor é uma maneira de ajudar a lidar com os riscos associados a isso. O restante desta seção discute o possível resultado de um cliente se conectar a um servidor não confiável.

As consequências de apontar uma DataAdapter fonte de dados não confiável dependem da implementação da DataAdapter própria.

SqlDataAdapter

Para o tipo interno SqlDataAdapter, fazer referência a uma fonte de dados não confiável pode resultar em um ataque de negação de serviço (DoS). O ataque DoS pode fazer com que o aplicativo pare de responder ou falhe. Se um invasor puder instalar uma DLL ao lado do aplicativo, ele também poderá conseguir a execução de código local.

Outros tipos de DataAdapter

Implementações de terceiros DataAdapter devem fazer suas próprias avaliações sobre quais garantias de segurança fornecem em face de entradas não confiáveis. O .NET não pode dar garantias de segurança em relação a essas implementações.

DataSet.ReadXml e DataTable.ReadXml

Os DataSet.ReadXml métodos e DataTable.ReadXml não são seguros quando usados com entradas não confiáveis. Recomendamos vivamente que, em vez disso, os consumidores considerem a utilização de uma das alternativas descritas mais adiante neste documento.

As implementações de e DataTable.ReadXml foram originalmente criadas antes das DataSet.ReadXml vulnerabilidades de serialização serem uma categoria de ameaça bem compreendida. Como resultado, o código não segue as práticas recomendadas de segurança atuais. Essas APIs podem ser usadas como vetores para que invasores executem ataques DoS contra aplicativos Web. Esses ataques podem fazer com que o serviço Web não responda ou resultar no encerramento inesperado do processo. A estrutura não fornece atenuações para essas categorias de ataque e o .NET considera esse comportamento "por design".

O .NET lançou atualizações de segurança para mitigar alguns problemas, como divulgação de informações ou execução remota de código em DataSet.ReadXml e DataTable.ReadXml. As atualizações de segurança do .NET podem não fornecer proteção completa contra essas categorias de ameaça. Os consumidores devem avaliar os seus cenários individuais e considerar a sua potencial exposição a esses riscos.

Os consumidores devem estar cientes de que as atualizações de segurança para essas APIs podem afetar a compatibilidade de aplicativos em algumas situações. Além disso, existe a possibilidade de que uma nova vulnerabilidade nessas APIs seja descoberta para a qual o .NET não possa praticamente publicar uma atualização de segurança.

Recomendamos que os consumidores dessas APIs:

  • Considere o uso de uma das alternativas descritas mais adiante neste documento.
  • Realize avaliações de risco individuais em seus aplicativos.

É da exclusiva responsabilidade do consumidor determinar se deve utilizar estas APIs. Os consumidores devem avaliar quaisquer riscos de segurança, técnicos e jurídicos, incluindo requisitos regulamentares, que possam acompanhar a utilização destas API.

DataSet e DataTable via ASP.NET serviços Web ou WCF

É possível aceitar uma DataSet ou uma DataTable instância em um serviço Web ASP.NET (SOAP), conforme demonstrado no código a seguir:

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. */
    }
}

Uma variação sobre isso não é aceitar DataSet ou DataTable diretamente como um parâmetro, mas sim aceitá-lo como parte do gráfico de objeto serializado SOAP geral, conforme mostrado no código a seguir:

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; }
}

Ou, usando WCF em vez de ASP.NET serviços Web:

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; }
}

Em todos esses casos, o modelo de ameaça e as garantias de segurança são os mesmos que a seção DataSet.ReadXml e DataTable.ReadXml.

Desserializar um DataSet ou DataTable via XmlSerializer

Os desenvolvedores podem usar XmlSerializer para desserializar DataSet e DataTable instâncias, conforme mostrado no código a seguir:

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; }
}

Nesses casos, o modelo de ameaça e as garantias de segurança são os mesmos que a seção DataSet.ReadXml e DataTable.ReadXml

Desserializar um DataSet ou DataTable via JsonConvert

O popular Json.NET de biblioteca Newtonsoft de terceiros pode ser usado para desserializar DataSet e DataTable instâncias, conforme mostrado no código a seguir:

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; }
}

Desserializar um DataSet ou DataTable dessa maneira de um blob JSON não confiável não é seguro. Esse padrão é vulnerável a um ataque de negação de serviço. Tal ataque pode travar o aplicativo ou torná-lo sem resposta.

Nota

A Microsoft não garante nem suporta a implementação de bibliotecas de terceiros como Newtonsoft.Json. Estas informações são fornecidas para exaustividade e são precisas no momento em que este artigo foi escrito.

Desserializar um DataSet ou DataTable via BinaryFormatter

Você nunca deve usar BinaryFormatter, NetDataContractSerializer, SoapFormatter, ou formatters não seguros relacionados para desserializar uma DataSet ou DataTable instância de uma carga não confiável:

  • Isso é suscetível a um ataque de execução remota de código completo.
  • Usar um costume SerializationBinder não é suficiente para evitar tal ataque.

Substituições seguras

Para aplicações que:

  • Aceite DataSet ou DataTable por meio de um ponto de extremidade .asmx SOAP ou um ponto de extremidade WCF.
  • Desserialize dados não confiáveis em uma instância de DataSet ou DataTable.

Considere substituir o modelo de objeto para usar o Entity Framework. Estrutura de entidades:

  • É uma estrutura rica, moderna e orientada a objetos que pode representar dados relacionais.
  • Traz um ecossistema diversificado de provedores de banco de dados para facilitar o projeto de consultas de banco de dados por meio de seus modelos de objeto do Entity Framework.
  • Oferece proteções internas ao desserializar dados de fontes não confiáveis.

Para aplicativos que usam .aspx pontos de extremidade SOAP, considere alterar esses pontos de extremidade para usar WCF. O WCF é um substituto mais completo para .asmx serviços Web. Os pontos de extremidade WCF podem ser expostos via SOAP para compatibilidade com chamadores existentes.

Analisadores de código

As regras de segurança do analisador de código, que são executadas quando o código-fonte é compilado, podem ajudar a encontrar vulnerabilidades relacionadas a esse problema de segurança no código C# e Visual Basic. Microsoft.CodeAnalysis.FxCopAnalyzers é um pacote NuGet de analisadores de código que é distribuído em nuget.org.

Para obter uma visão geral dos analisadores de código-fonte, consulte Visão geral dos analisadores de código-fonte.

Habilite as seguintes regras Microsoft.CodeAnalysis.FxCopAnalyzers:

  • CA2350: Não use DataTable.ReadXml() com dados não confiáveis
  • CA2351: Não use DataSet.ReadXml() com dados não confiáveis
  • CA2352: DataSet ou DataTable não seguros em tipo serializável podem ser vulneráveis a ataques de execução remota de código
  • CA2353: DataSet ou DataTable não seguro no tipo serializável
  • CA2354: DataSet ou DataTable não seguros no gráfico de objetos desserializados podem ser vulneráveis a ataques de execução remota de código
  • CA2355: Tipo DataSet ou DataTable não seguro encontrado no gráfico de objeto desserializável
  • CA2356: Tipo de DataSet ou DataTable não seguro no gráfico de objeto desserializável da Web
  • CA2361: Verifique se a classe gerada automaticamente que contém DataSet.ReadXml() não é usada com dados não confiáveis
  • CA2362: DataSet ou DataTable não seguros no tipo serializável gerado automaticamente podem ser vulneráveis a ataques de execução remota de código

Para obter mais informações sobre como configurar regras, consulte Usar analisadores de código.

As novas regras de segurança estão disponíveis nos seguintes pacotes NuGet:

  • Microsoft.CodeAnalysis.FxCopAnalyzers 3.3.0: para Visual Studio 2019 versão 16.3 ou posterior
  • Microsoft.CodeAnalysis.FxCopAnalyzers 2.9.11: para Visual Studio 2017 versão 15.9 ou posterior