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 seguinte código inicializa um NSURLCredential usando uma relação de 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 seguinte aplicativo 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);
} 

A variável global tx.origin contém o endereço da conta de onde a transação se origina.

Se um contrato inteligente, S1, recebe uma transação de uma conta, A1, e então S1 chama outro contrato inteligente, S2, e dentro de S2, tx.origin contém o endereço da conta, A1, usada para chamar S1. Se a intenção de tx.origin for verificar a autorização de A1, essa autorização será ignorada.

Agora, se um invasor puder enganar um usuário para que envie uma transação em um contrato malicioso, ele invocará o contrato vulnerável onde o usuário está autorizado via tx.origin, então tx.origin manterá o endereço da conta do usuário que iniciou a transação e a autorização será ignorada.

Exemplo 1: O código a seguir exige que o proprietário do contrato (previamente definido no construtor) seja o mesmo que tx.origin antes de transferir fundos para um endereço fornecido.

Se um invasor conseguir enganar o proprietário do contrato para que envie uma transação para um contrato malicioso que chama imediatamente a função sendTo no contrato vulnerável, então a condição na instrução require será verdadeira e os fundos serão transferidos para qualquer endereço especificado pelo contrato do invasor ao chamar sendTo.

function sendTo(address receiver, uint amount) public {
    require(tx.origin == owner);
    receiver.transfer(amount);
}

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