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" %>

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.

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.

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.

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

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;

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
}

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

Uma configuração curinga para lambda principais viola o princípio de privilégios mínimos e permite que um invasor invoque o lambda de qualquer conta.

Exemplo 1: A tarefa do Ansible de exemplo a seguir define uma principal lambda curinga.

- name: Create Lambda policy statement for S3 event notification
  community.aws.lambda_policy:
    action: lambda:InvokeFunction
    function_name: functionName
    principal: *
    statement_id: lambda-s3-demobucket-access-log
    source_arn: arn:aws:s3:us-west-2:123456789012:demobucket
    source_account: 123456789012
    state: present

Os clusters do Amazon Redshift não são, por padrão, acessíveis publicamente.

Habilitar o acesso público a um cluster resulta em uma superfície de ataque mais ampla para a organização.

Exemplo 1: O exemplo a seguir mostra uma tarefa Ansible que habilita explicitamente o acesso público a um cluster do Amazon Redshift configurando o parâmetro publicly_accessible como yes .

- name: example1
  community.aws.redshift:
    identifier: mycluster
    command: create
    db_name: mydb
    node_type: ds1.xlarge
    username: "{{ username }}"
    password: "{{ password }}"
    publicly_accessible: yes

Uma configuração incorreta de acesso público a um bucket do S3 é uma das principais causas das violações de dados.

Embora os buckets do S3 bloqueiem o acesso público por padrão, qualquer usuário autorizado pode atualizar as políticas de bucket ou listas de controle de acesso (ACLs) para permitir o acesso público.

Uma AMI do Amazon EC2 que mapeia um dispositivo de bloco não criptografado expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: A tarefa do Ansible a seguir cria uma AMI do Amazon EC2 e anexa um dispositivo de bloco sem criptografia de dados em repouso à AMI porque o parâmetro encrypted está definido como false.

- name: Basic AMI Creation
  amazon.aws.ec2_ami:
    state: present
    instance_id: i-xxxxxx
    name: test_ami
    device_mapping:
      device_name: /dev/sda
      encrypted: false

Por padrão, um sistema de arquivos do EFS não é criptografado. Isso expõe os dados a acesso não autorizado e possível roubo.

Exemplo 1: A tarefa do Ansible a seguir configura um sistema de arquivos do EFS sem criptografia de dados em repouso porque o parâmetro encrypt está definido como no.

- name: EFS provisioning
  community.aws.efs:
    state: present
    name: myTestEFS
    encrypt: no
    targets:
      - subnet_id: subnet-12345678
        security_groups: [ "sg-87654321" ]