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

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 chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

Por padrão, a AWS usa chaves gerenciadas pela AWS para criptografar dados em repouso se a criptografia estiver habilitada. As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle e registro de processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Observe que as chaves com o formato aws/service-name são reservadas para chaves gerenciadas pela AWS.

Configurações de acesso livre podem expor sistemas e ampliar a superfície de ataque de uma organização. Os serviços abertos à interação com o público são normalmente submetidos a varreduras e investigações quase contínuas por entidades mal-intencionadas.

Isso é especialmente problemático quando uma exploração de dia zero para um serviço exposto é descoberta e publicada, como Heartbleed. Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

O acesso descontrolado a recursos críticos ou confidenciais pode afetar significativamente uma organização de várias maneiras, incluindo a divulgação ou adulteração de dados críticos.