O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpsRedirection() adiciona o middleware de redirecionamento HTTPS ao pipeline de middleware, que permite o redirecionamento de solicitações HTTP não seguras para uma solicitação HTTPS segura. Quando especificado na ordem errada, conforme mostrado, nenhum redirecionamento HTTPS significativo ocorrerá antes de processar a solicitação por meio do middleware listado antes do redirecionamento. Isso permitirá que as solicitações HTTP sejam processadas pelo aplicativo antes de serem redirecionadas para a conexão HTTPS segura.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

O middleware ASP.NET Core que não é adicionado ao pipeline de middleware na ordem correta não funcionará conforme o esperado, deixando um aplicativo aberto a vários problemas de segurança.

Exemplo 1: O método UseHttpLogging() adiciona middleware de registro em log HTTP ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseHttpLogging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

Exemplo 2: O método UseWC3Logging() adiciona o middleware de registro em log do W3C ao pipeline de middleware que permite que os componentes de middleware sejam registrados em log. Quando especificado na ordem errada, conforme mostrado, nenhum middleware adicionado ao pipeline antes da chamada para UseWC3Logging() será registrado em log.

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

Definir o modo de validação do certificado como None desativa todo o processo de validação do certificado, o que expõe a aplicação a ataques Man-in-the-Middle. Esse modo nunca deve ser usado em ambientes de produção.

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.

Os aplicativos ASP .NET podem ser configurados para produzir binários de depuração. Esses binários fornecem mensagens de depuração detalhadas e não devem ser usados em ambientes de produção. O atributo debug da tag <compilation> define se os binários compilados devem incluir informações de depuração.

O uso de binários de depuração faz com que um aplicativo forneça ao usuário o máximo de informações possível sobre si mesmo. Os binários de depuração devem ser usados em um ambiente de desenvolvimento ou teste e podem representar um risco de segurança se forem implantados em produção. Os invasores podem aproveitar as informações adicionais adquiridas com a saída de depuração para prepararem ataques direcionados no banco de dados da infraestrutura ou a outros recursos usados pelo aplicativo.

A validação de eventos é um recurso de segurança do ASP.NET que valida os controles de eventos em solicitações de postback para garantir que os controles sejam os mesmos de quando foram renderizados durante o carregamento inicial da página. Quando esse recurso está desativado, os invasores podem realizar ataques de falsificação de solicitação entre sites com controles de eventos adulterados, levando a acessos não autorizados, ataques de script entre sites etc.

Exemplo 1: A configuração do aplicativo Web a seguir desativa a validação de eventos.

...
<system.web>
    ...
    <pages enableEventValidation="false">
    ...
    </pages>
</system.web>

Exemplo 2: A diretiva de página do servidor a seguir desativa a validação de eventos.

<%@ Page ... EnableEventValidation="false" %>

Quanto mais tempo uma sessão fica aberta, maior a janela de oportunidade que um invasor tem para comprometer contas de usuário. Enquanto uma sessão permanece ativa, um invasor pode ser capaz de aplicar força bruta à senha de um usuário, quebrar a chave de criptografia sem fio de um usuário ou comandar uma sessão de um navegador aberto. Tempos limites de autenticação mais longos também podem impedir que a memória seja liberada e, eventualmente, resultar em uma denial of service se um número suficientemente grande de sessões for criado.

Exemplo 1: O exemplo a seguir mostra a ASP.NET MVC configurada com um tempo limite de autenticação de uma hora.

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

Se o atributo de tempo limite não for especificado, o tempo limite de autenticação será de 30 minutos.

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.