Antes de crear una credencial de confianza del servidor, es responsabilidad del delegado de un objeto NSURLConnection, un objeto NSURLSession o un objeto NSURLDownload evaluar la cadena de confianza.

Ejemplo 1: el siguiente código inicializa un NSURLCredential mediante una credencial de confianza del servidor no evaluada:

-(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 de crear una credencial de confianza del servidor, es responsabilidad del delegado de un objeto NSURLConnection, objeto NSURLSession o un objeto NSURLDownload evaluar la confianza del servidor. Para poder evaluar la confianza del servidor, debe llamarse al método SecTrustEvaluate(_:_:) con la confianza obtenida del método serverTrust del objeto del servidor NSURLProtectionSpace.

El método SecTrustEvaluate(_:_:) devuelve dos valores diferentes:

- El valor OSStatus devuelto representa el código de resultado.
- El objeto indicado por el segundo argumento representa el tipo de resultado de la evaluación.

Si la confianza no es válida, el desafío de autenticación debe cancelarse con cancel(_:).

Ejemplo 1: en el ejemplo siguiente, la confianza del servidor se evalúa, pero las credenciales recibidas se utilizan sin comprobar el resultado de la evaluación:

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

Un objeto NSURLProtectionSpace representa un servidor o un área de un servidor, denominado comúnmente dominio, que requiere autenticación.
Al establecer una conexión URL que requiera autenticación en un espacio de protección, el método NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) se llamará justo antes de llamar al método NSURLConnectionDelegate.connection(_:didReceive:) que debe realizar la autenticación. Esto permite que NSURLConnectionDelegate inspeccione el espacio de información antes de intentar la autenticación. Al devolver true, el delegado indica que puede manejar el formulario de autenticación, lo que hace en la llamada subsiguiente a connection(_:didReceive:). Si su delegado no implementa este método y el espacio de protección utiliza la autenticación del certificado de cliente o la autenticación de confianza del servidor, el sistema intentará utilizar las llaves del usuario para realizar la autenticación, lo cual puede no ser el comportamiento deseado.

La aplicación implementa las llamadas de retorno NSURLConnection o NSURLSession para tratar solicitudes de autenticación. Si olvida comprobar que la solicitud de autenticación proviene del host esperado, las credenciales se enviarán a todas las URL que cargue la aplicación. Además, si no verifica que las credenciales se pueden enviar de forma segura, las credenciales serán susceptibles de ser robadas.

Ejemplo 1: la aplicación siguiente envía credenciales de usuario a cualquier host que solicite autenticación:

- (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);
} 

La variable global tx.origin contiene la dirección de la cuenta desde donde se origina una transacción.

Si un contrato inteligente, S1, recibe una transacción de una cuenta, A1, y luego S1 llama a otro contrato inteligente, S2, entonces, dentro de S2, tx.origin contiene la dirección de la cuenta, A1, utilizada para llamar a S1. Si la intención de tx.origin es verificar la autorización de A1, esta autorización se elude.

Ahora, si un atacante puede engañar a un usuario para que envíe una transacción a un contrato malicioso que luego invoca el contrato vulnerable, donde el usuario está autorizado a través de tx.origin, entonces tx.origin contendrá la dirección de la cuenta de usuario que inició la transacción y se eludirá la autorización.

Ejemplo 1: El siguiente código requiere que el propietario del contrato (previamente establecido en el constructor) sea el mismo que tx.origin antes de transferir fondos a una dirección proporcionada.

Si un atacante puede engañar al propietario del contrato para que envíe una transacción a un contrato malicioso que inmediatamente llame a la función sendTo en el contrato vulnerable, la condición dentro de la declaración require será verdadera y los fondos se transferirán a cualquier dirección que el contrato del atacante haya especificado al llamar a sendTo.

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

Las configuraciones de acceso dinámico exponen innecesariamente los sistemas y amplían la superficie de ataque de una organización. Los servicios abiertos a la interacción con el público suelen estar sujetos a análisis y sondeos casi continuos por parte de entidades malintencionadas.

Esto es especialmente problemático cuando se descubre y publica una vulnerabilidad de día cero para un servicio expuesto (por ejemplo, Heartbleed). Los atacantes pueden perseguir y buscar activamente sistemas expuestos y sin revisión que puedan aprovechar.

Ejemplo 1: La siguiente tarea de Ansible define un grupo de seguridad de AWS que abre al mundo (0.0.0.0/0 ) el puerto TCP22, donde un servidor SSH suele responder a las solicitudes de conexión entrantes.

- 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

Una configuración comodín para los principales lambda infringe el principio de privilegios mínimos y permite que un atacante invoque el lambda desde cualquier cuenta.

Ejemplo 1: La siguiente tarea de Ansible de ejemplo define un principal lambda comodín.

- 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