Por padrão, o .NET Framework impede que caracteres de nova linha sejam enviados para APIs que definem valores de cabeçalho HTTP. No entanto, esse comportamento pode ser desabilitado programaticamente, definindo a propriedade EnableHeaderChecking no objeto HttpRuntimeSection como false.

Exemplo 1: O código a seguir desabilita a verificação de cabeçalhos.

Configuration config = WebConfigurationManager.OpenWebConfiguration("/MyApp");
HttpRuntimeSection hrs = (HttpRuntimeSection) config.GetSection("system.web/httpRuntime");
hrs.EnableHeaderChecking = false;

Quando essa verificação está desabilitada, o código que permite que a entrada do usuário alcance as APIs de definição de cabeçalho fica vulnerável a ataques como a Divisão de Respostas HTTP.

Os programas podem ser configurados para validar certificados X.509 de uma das três maneiras. Por padrão, os certificados são validados por meio de sua cadeia de confiança de volta para uma autoridade raiz confiável. Esta configuração é conhecida como ChainTrust e oferece o nível máximo de garantia de que o certificado é válido. Por padrão, todos os certificados são validados usando o ChainTrust .

Para usar um certificado que não foi emitido por uma autoridade raiz confiável, um programa pode ser configurado para confiar em certificados emitidos por seus pares, definindo PeerTrust ou PeerOrChainTrust . Essas configurações não devem ser usadas em ambientes de produção porque reduzem significativamente o nível de segurança concedido pelos certificados.

Os cookies são frequentemente usados para armazenar informações importantes sobre os usuários, como informações pessoais, tokens de autenticação e um histórico de suas atividades. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de proteger o conteúdo do cookie e verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Se o atributo cacheRolesInCookie do elemento configuration/system.web/authentication/forms em web.config está configurado como true, as funções de cada usuário são armazenadas em cache em um cookie. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

Os serviços da web ASP.NET facilitam o desenvolvimento de clientes de serviços da web, gerando automaticamente a documentação que descreve como se comunicar com o serviço da web.

Os serviços da web que têm o protocolo de documentação ativado geram uma página formatada em HTML quando uma solicitação do navegador é recebida.

Esta página formatada em HTML descreve as seguintes informações:
1. As operações que são suportadas
2. Os parâmetros que cada operação aceita
3. O tipo de dado que deve ser passado nesses parâmetros

O protocolo de documentação também gera um arquivo WSDL (Web Services Description Language) formatado em XML. Este arquivo foi projetado para permitir que os aplicativos entendam como estruturar as solicitações para o serviço da web. Essas informações podem ser muito úteis para desenvolvedores, especialmente desenvolvedores que criam clientes para serviços da web públicos. No entanto, revelar informações detalhadas sobre a funcionalidade de serviços da web privados aumenta o risco de que o serviço da web seja usado indevidamente por um invasor mal-intencionado. O protocolo de documentação sempre descreve todas as funções e parâmetros de um serviço da web - mesmo se apenas um subconjunto dessas funções se destina a ser acessível publicamente.

Esse aplicativo ASP.NET Core não configura controladores ou métodos de controlador de natureza confidencial para serem acessíveis apenas por meio de uma conexão segura.

ASP.NET W3Clogger.loggingFields pode ser configurado para permitir o registro de dados confidenciais, como dados privados e do sistema Informação.
Esses dados podem conter informações confidenciais relacionadas a solicitações HTTP e respostas HTTP, como clientes/IP do servidor, portas do servidor, cookies de cabeçalho e nomes de usuários autenticados que acessaram o servidor.

Em caso de violação de dados, o adversário pode usar essas informações para:

- Roubar informações confidenciais ou representar um usuário com privilégios mais altos.
- Descobrir servidores internos e obter acesso não autorizado a recursos restritos.
- Elaborar ataques concentrados em explorar vulnerabilidades conhecidas relatadas contra o servidor detectado


Exemplo 1: O seguinte código mostra um método de ação em um controlador em que a validação foi desativada:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 mostra como o W3Clogging pode ser configurado, usando o sinalizador All, para registrar todos os campos possíveis na Solicitação Http, incluindo dados confidenciais, como ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName e Cookie.

Os aplicativos ASP .NET devem ser configurados para usar páginas de erro personalizadas em vez da página padrão da estrutura. A página de erro padrão fornece informações detalhadas sobre o erro ocorrido e não deve ser usada em ambientes de produção. O atributo mode da tag <customErrors> define se páginas de erro personalizadas ou padrão são usadas.

Os invasores podem aproveitar as informações adicionais fornecidas por uma página de erro padrão para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

Por padrão, o ASP.NET valida internamente as assinaturas criptográficas antes de descriptografar cargas úteis, como ViewState, FormsAuth cookies e URLs ScriptResource.axd e passa esses valores para o aplicativo para processamento posterior. No entanto, essa funcionalidade pode ser modificada usando a configuração aspnet:UseLegacyEncryption para desativar a verificação de assinatura criptográfica antes de descriptografar cargas úteis. Isso pode permitir que um cliente mal-intencionado descriptografe, falsifique ou adultere dados criptografados.

Exemplo 1: No exemplo a seguir, aspnet:UseLegacyEncryption está definido como true.

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

Os aplicativos ASP.NET podem armazenar pares de nome de usuário e senha em elementos <credentials> no arquivo web.config de um aplicativo ASP.NET, que suporta texto simples e formatos de senha MD5 e SHA1.

As senhas armazenadas em texto simples ou usando um algoritmo de criptografia fraco são acessíveis a qualquer pessoa com acesso aos arquivos de configuração do aplicativo. Isso pode incluir a máquina onde o aplicativo está hospedado ou o repositório de código-fonte onde o aplicativo reside.

Exemplo 1: A seguinte entrada web.config armazena incorretamente suas senhas em texto simples.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

O ASP.NET oferece suporte a senhas de credenciais armazenadas em três formatos, especificados pelo atributo passwordFormat do elemento configuration/system.web/authentication/forms/credentials. Os valores possíveis para este atributo são:

Clear - indica que a senha está armazenada em texto simples (menos seguro)
MD5 - indica que o hash MD5 da senha está armazenado
SHA1 - indica que o hash SHA1 da senha está armazenado (mais seguro)

Embora um hash MD5 seja mais seguro do que texto simples, os pesquisadores descobriram ataques de força bruta contra o algoritmo de hash MD5. No momento, um hash SHA1 ainda fornece proteção razoável contra esses ataques.

O método FormsAuthentication.RedirectFromLoginPage() emite um tíquete de autenticação, que permite que os usuários permaneçam autenticados por um período de tempo especificado. Quando o método é invocado com o segundo argumento false, ele emite um tíquete de autenticação temporário que permanece válido por um período de tempo configurado em web.config. Quando invocado com o segundo argumento true, o método emite um tíquete de autenticação persistente. No .NET 2.0, o tempo de vida do tíquete persistente respeita o valor em web.config, mas, no .NET 1.1, esse tíquete de autenticação persistente tem um tempo de vida padrão ridiculamente longo -- cinquenta anos.

Permitir que tíquetes de autenticação persistentes sobrevivam por um longo período de tempo deixa os usuários e o sistema vulneráveis das seguintes maneiras:

Expande o período de exposição a ataques de sequestro de sessão para usuários que não conseguem fazer logout.

Aumenta o número médio de identificadores de sessão válidos disponíveis para um invasor adivinhar.

Prolonga a duração da exploração quando um invasor consegue sequestrar a sessão de um usuário.

Entradas não verificadas são a principal causa de vulnerabilidades em aplicativos ASP.NET. Entradas não verificadas podem resultar em muitas vulnerabilidades, incluindo cross-site scripting, process control e SQL injection.

Para evitar esses ataques, use a estrutura de validação ASP.NET para verificar todas as entradas do programa antes que elas sejam processadas pelo aplicativo.

Exemplos de uso da estrutura de validação incluem verificações para garantir que:

- Campos de número de telefone contenham somente caracteres válidos em números de telefone
- Valores boolianos sejam somente "T" ou "F"
- Cadeias de forma livre tenham um comprimento e uma composição razoáveis

Se o atributo cacheRolesInCookie do elemento configuration/system.web/authentication/forms em web.config está configurado como true, as funções de cada usuário são armazenadas em cache em um cookie. Se essas informações forem armazenadas em texto simples, qualquer pessoa com acesso às máquinas utilizadas para interagir com o aplicativo terá acesso às informações armazenadas no cookie. Pior ainda, se os invasores tiverem permissão para modificar arbitrariamente os dados armazenados nos cookies, eles podem falsificar as informações fornecidas ao aplicativo e, possivelmente, alterar o comportamento a seu favor.

Em muitos casos, um aplicativo pode validar a entrada de cookies programaticamente de acordo com o contexto em que é usado, mas a estrutura de validação do ASP.NET fornece uma maneira excelente de verificar se o cookie não foi modificado inesperadamente. Sem essa abordagem, é difícil e, muitas vezes impossível, estabelecer com um alto nível de confiança que todas as entradas foram validadas.

A maioria dos aplicativos da web usa um identificador de sessão para identificar exclusivamente os usuários, que normalmente é armazenado em um cookie e transmitido de forma transparente entre o servidor e o navegador da web.


Quando o valor do atributo está definido como true ou UseUri , o aplicativo não usa cookies, independentemente de o navegador ou dispositivo oferecer suporte a cookies. Quando o valor do atributo está definido como AutoDetect ou UseDeviceProfile, os cookies não são usados dependendo da configuração do navegador ou dispositivo solicitante.

Os aplicativos que não armazenam identificadores de sessão em cookies às vezes os transmitem como um parâmetro de solicitação HTTP ou como parte da URL. Aceitar identificadores de sessão especificados em URLs torna mais fácil para invasores realizar ataques de fixação de sessão.

Colocar identificadores de sessão em URLs também pode aumentar as chances de ataques de sequestro de sessão bem-sucedidos contra o aplicativo. O sequestro de sessão ocorre quando um invasor assume o controle da sessão ativa da vítima ou do identificador de sessão. É uma prática comum para servidores da web, servidores de aplicativos e proxies da web armazenar URLs solicitados. Se identificadores de sessão forem incluídos em URLs, eles também serão registrados. Aumentar o número de locais onde os identificadores de sessão são exibidos e armazenados aumenta as chances de serem comprometidos por um invasor.

Aplicativos ASP.NET podem ser configurados para processar a saída de informações de depuração de rastreamento. A saída de rastreamento contém detalhes sobre a solicitação feita à página atual, bem como informações de cabeçalho, métodos e controles usados na página e o estado da sessão ativa. Os invasores podem aproveitar as informações adicionais adquiridas com a saída do rastreamento para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

As informações de rastreamento são habilitadas no nível da página, definindo o atributo Trace da diretiva <page> como true ou no nível do aplicativo, adicionando um elemento trace no arquivo web.config e definindo seu atributo enabled como true .

O processamento inseguro de cabeçalho HTTP existe definindo a propriedade useUnsafeHeaderParsing como true. Essa configuração permite ataques contra aplicativos vulneráveis devido a regras de validação insuficientes em cabeçalhos HTTP.

A validação a seguir NÃO é realizada quando esse atributo está definido como true:

- Use CRLF para código de fim de linha. Um CR ou LF separado não é permitido.
- Sem espaços nos nomes dos cabeçalhos.
- Todas, exceto a primeira linha de status, são interpretadas como um par de nome/valor do cabeçalho com defeito.
- A linha de status deve incluir um código e uma descrição.

Essa configuração também significa que certas exceções relativas a caracteres proibidos não serão mais lançadas.

Exemplo 1: No exemplo a seguir, useUnsafeHeaderParsing está definido como "true".

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

O uso de credenciais personificadas permite que um aplicativo ASP.NET seja executado com os privilégios do cliente em cujo nome ele está executando ou com privilégios arbitrários concedidos em sua configuração.

No ASP.NET, o estado de exibição é um mecanismo para manter o estado persistente em formulários da Web entre postbacks. Os dados armazenados no estado de exibição não são confiáveis, pois não há um mecanismo para evitar ataques de reprodução. Confiar no estado de exibição é particularmente perigoso quando a verificação de autenticação de mensagens para estados de exibição está desabilitada. Desabilitar essa verificação permite que os invasores façam alterações arbitrárias nos dados armazenados no estado de exibição e pode abrir as portas para ataques contra um código que confia nesse estado de exibição. Os invasores podem usar esse tipo de erro para derrotar verificações de autenticação ou alterar os preços de itens.
Exemplo 1: O código a seguir desabilita verificações de autenticação de mensagens de estado de exibição.

Page.EnableViewStateMac = false;

Os aplicativos ASP.NET podem armazenar pares de nome de usuário e senha em elementos <credentials> no arquivo web.config de um aplicativo ASP.NET, que suporta texto simples e formatos de senha MD5 e SHA1.

As senhas armazenadas em texto simples ou usando um algoritmo de criptografia fraco são acessíveis a qualquer pessoa com acesso aos arquivos de configuração do aplicativo. Isso pode incluir a máquina onde o aplicativo está hospedado ou o repositório de código-fonte onde o aplicativo reside.

Exemplo 1: A seguinte entrada web.config armazena incorretamente suas senhas em texto simples.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

O ASP.NET oferece suporte a senhas de credenciais armazenadas em três formatos, especificados pelo atributo passwordFormat do elemento configuration/system.web/authentication/forms/credentials. Os valores possíveis para este atributo são:

Clear - indica que a senha está armazenada em texto simples (menos seguro)
MD5 - indica que o hash MD5 da senha está armazenado
SHA1 - indica que o hash SHA1 da senha está armazenado (mais seguro)

Embora um hash MD5 seja mais seguro do que texto simples, os pesquisadores descobriram ataques de força bruta contra o algoritmo de hash MD5. No momento, um hash SHA1 ainda fornece proteção razoável contra esses ataques.

As ações do controlador ASP.NET MVC que modificam dados gravando, atualizando ou excluindo podem se beneficiar da restrição de aceitar um dos seguintes verbos HTTP: Post, Put, Patch ou Delete. Isso aumenta a dificuldade de falsificação de solicitação entre sites, pois o clique acidental de links não fará com que a ação seja executada.

A ação de controlador a seguir aceita qualquer verbo por padrão e pode ser suscetível a falsificação de solicitações entre sites:

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}