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.

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.

A entrada não verificada é a principal causa de vulnerabilidades em aplicativos ASP.NET. A entrada não verificada pode levar a inúmeras vulnerabilidades, incluindo cross-site scripting, controle de processo e SQL injection.

Para evitar tais ataques, use a estrutura de validação do ASP.NET para verificar todas as entradas do programa antes delas serem processadas pelo aplicativo.

Os exemplos de uso da estrutura de validação incluem a verificação para garantir que:

- Os campos de número de telefone contêm apenas caracteres válidos em números de telefone

- Os valores booleanos são apenas "T" ou "F"

- Cadeias de caracteres de forma livre têm tamanho e 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.