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
}

O MVC ASP.NET fornece uma maneira conveniente de proteger melhor um aplicativo contra falsificação de solicitações entre sites, adicionando um token antifalsificação no lado do formulário e validando esse token no controlador. Se usado, esse token é geralmente incluído como um campo de formulário oculto, sendo validado quando o formulário é enviado, o que aumenta as chances de uma solicitação ser proveniente do seu aplicativo e não falsificada.

O código de controlador a seguir não inclui defesa interna contra falsificação de solicitações entre sites:

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

O MVC ASP.NET fornece uma maneira conveniente de proteger melhor um aplicativo contra falsificação de solicitações entre sites, adicionando um token antifalsificação ao formulário HTML e validando esse token no controlador. Se usado, esse token é geralmente incluído como um campo de formulário oculto, sendo validado quando o formulário é enviado, o que aumenta as chances de uma solicitação ser proveniente do seu aplicativo e não falsificada.

Em geral, um programador deve incluir esse token antifalsificação, pois ele aumenta o custo de criação de scripts mal-intencionados contra um aplicativo.

Exemplo 1:o seguinte código Razor cria um formulário no HTML resultante sem a defesa integrada contra falsificação de solicitação entre sites:

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

Usar uma classe de modelo que possui propriedades obrigatórias (marcadas com o atributo [Required]) e propriedades opcionais (não marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém mais dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

O fato de haver níveis combinados de exigência sem a comunicação explícita de quais parâmetros devem ser associados a modelos pode indicar que existem propriedades de modelo para uso interno, mas que essas propriedades podem ser controladas por um invasor.

O código a seguir define uma possível classe de modelo que tem propriedades com [Required] e propriedades sem [Required]:

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

Se qualquer parâmetro opcional puder alterar o comportamento de um aplicativo, talvez um invasor seja capaz de realmente mudar esse comportamento comunicando um parâmetro opcional em uma solicitação.

Usar uma classe de modelo que possui propriedades obrigatórias não anuláveis (marcadas com o atributo [Required]) pode provocar problemas quando um invasor comunica uma solicitação que contém menos dados do que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo.

Se um modelo tiver um parâmetro obrigatório não anulável e um invasor não comunicar esse parâmetro em uma solicitação -- ou seja, se o invasor usar um ataque under-posting --, a propriedade terá o valor padrão (geralmente zero), que atenderá ao atributo de validação [Required]. Isso pode provocar o comportamento inesperado do aplicativo.

O código a seguir define uma classe de modelo possível que possui uma enumeração obrigatória não anulável:

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

Se uma classe de modelo tiver a propriedade obrigatória e for do tipo de um membro opcional de uma classe de modelo pai, ela poderá ser suscetível a ataques under-posting se um invasor comunicar uma solicitação contendo menos dados que o esperado.

A estrutura MVC ASP.NET tentará associar parâmetros de solicitação a propriedades de modelo, incluindo submodelos.

Se um submodelo for opcional -- ou seja, se o modelo pai tiver uma propriedade sem o atributo [Required] -- e se um invasor não comunicar esse submodelo, então a propriedade pai terá um valor null, e os campos obrigatórios do modelo filho não serão confirmados pela validação de modelo. Essa é uma das formas de ataque under-posting.

Considere as seguintes definições de classe de modelo:

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

Se um invasor não comunicar um valor para a propriedade ParentModel.Child, a propriedade ChildModel.RequiredProperty terá um [Required] não confirmado. Isso pode produzir resultados inesperados e indesejáveis.

O método do representante NSURLConnectionDelegate.connection(_:willSendRequestFor:) permite que o representante tome imediatamente uma decisão bem-informada sobre a autenticação de conexão. Se o representante implementar esse método, não será necessário implementar NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) ou NSURLConnectionDelegate.connection(_:didReceive:). Na verdade, esses métodos não são chamados e, portanto, qualquer verificação de segurança neles será ignorada.

Antes da criação de uma credencial de confiança de servidor, é responsabilidade do representante de um objeto NSURLConnection, de um objeto NSURLSession ou de um objeto NSURLDownload avaliar a cadeia de confiança.

Exemplo 1: O código a seguir inicializa NSURLCredential usando uma confiança de servidor não avaliada:

-(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * credential)) completionHandler {
        ...
        [challenge.sender useCredential:[NSURLCredential credentialForTrust: challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
        ...
}

Antes da criação de uma credencial de confiança de servidor, é responsabilidade do representante de um objeto NSURLConnection, de um objeto NSURLSession ou de um objeto NSURLDownload avaliar a relação de confiança do servidor. A fim de avaliar a relação de confiança do servidor, o método SecTrustEvaluate(_:_:) deve ser chamado com a confiança obtida do método serverTrust do objeto NSURLProtectionSpace do servidor.

O método SecTrustEvaluate(_:_:) retorna dois valores diferentes:

- O valor OSStatus retornado representa o código de resultado.
- O objeto apontado pelo segundo argumento representa o tipo de resultado da avaliação.

Se a confiança for inválida, o desafio de autenticação deverá ser cancelado com cancel(_:).

Exemplo 1: No exemplo a seguir, a relação de confiança do servidor é avaliada, mas as credenciais recebidas são usadas sem verificar o resultado dessa avaliação:

SecTrustRef trust = [[challenge protectionSpace] serverTrust];
SecTrustResultType result = kSecTrustResultInvalid;
OSStatus status = SecTrustEvaluate(trust, &result);
completionHandler(NSURLSessionAuthChallengeUseCredential, [challenge proposedCredential]);

Um objeto NSURLProtectionSpace representa um servidor ou uma área em um servidor, comumente chamada de realm, que requer autenticação.
Ao estabelecer uma conexão de URL que requer autenticação em um espaço de proteção, o método NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) será chamado logo antes da chamada para o método NSURLConnectionDelegate.connection(_:didReceive:) que deve realizar a autenticação. Isso permite que NSURLConnectionDelegate inspecione o espaço de proteção antes de tentar se autenticar nele. Ao retornar true, o representante indica que pode lidar com a forma de autenticação, o que acontece na chamada subsequente para connection(_:didReceive:). Se o seu representante não implementar esse método, e o espaço de proteção usar a autenticação de certificado de cliente ou a autenticação por confiança de servidor, o sistema tentará usar a cadeia de chaves do usuário para a autenticação, o que pode não ser o comportamento desejado.

O aplicativo implementa os retornos de chamada NSURLConnection ou NSURLSession para manipular solicitações de autenticação. Se não forem realizadas ações para garantir que a solicitação de autenticação seja proveniente do host esperado, será possível que credenciais sejam enviadas para cada URL carregada pelo aplicativo. Além disso, se não for feita uma verificação para garantir que as credenciais possam ser enviadas de forma segura, será possível que elas sejam roubadas.

Exemplo 1: O aplicativo a seguir envia as credenciais do usuário para qualquer host que esteja solicitando autenticação:

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NS URLAuthenticationChallenge *)challenge completionHandler:(void (^)(NS URLSessionAuthChallengeDisposition, NSURLCredential *))completionHandler { 
    NSString *user = [self getUser]; 
    NSString *pass = [self getPassword]; 

    NSURLCredential *cred = [NSURLCredential credentialWithUser:user 
    password:pass persistence:NSURLCredentialPersistenceForSession]; 
    completionHandler(NSURLSessionAuthChallengeUseCredential, credential);
} 

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.

As configurações de acesso livre expõem os sistemas desnecessariamente e ampliam 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 um exploit de dia zero para um serviço exposto é descoberto e publicado (por exemplo, Heartbleed). Os invasores podem perseguir e pesquisar ativamente sistemas não corrigidos e expostos para explorá-los.

Exemplo 1: A seguinte tarefa Ansible define um Grupo de segurança AWS que abre para o mundo (0.0.0.0/0 ) a porta TCP 22 , onde um servidor SSH normalmente responde às solicitações de conexão de entrada.

- name: Task to open SSH port
  amazon.aws.ec2_group:
    name: demo_security_group
    description: Open the ssh port to the world
    state: present
    vpc_id: 123456
    region: us-west-1
    rules:
    - proto: tcp
        ports: 22
        cidr_ip: 0.0.0.0/0