创建服务器信任凭证之前，NSURLConnection 对象、NSURLSession 对象或 NSURLDownload 对象的代理负责评估信任链。

示例 1：以下代码使用未经评估的服务器信任来初始化 NSURLCredential：

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

创建服务器信任凭证之前，NSURLConnection 对象、NSURLSession 对象或 NSURLDownload 对象的代理负责评估服务器信任。为了评估服务器信任，应在已从服务器 NSURLProtectionSpace 对象的 serverTrust 方法获取信任的情况下调用 SecTrustEvaluate(_:_:) 方法。

SecTrustEvaluate(_:_:) 方法返回两个不同的值：

- 返回的 OSStatus 值表示结果代码。
- 第二个参数所指的对象表示评估的结果类型。

如果信任无效，应使用 cancel(_:) 取消身份验证质询。

示例 1：在下面的示例中，评估了服务器信任，但却在未检查此评估结果的情况下使用了收到的凭证：

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

NSURLProtectionSpace 对象代表需要身份验证的服务器或服务器上的某个区域（通常称为 Realm）。
当建立需要对保护空间进行身份验证的 URL 连接时，将在调用 NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) 方法之后立即调用应执行身份验证的 NSURLConnectionDelegate.connection(_:didReceive:) 方法。这样，NSURLConnectionDelegate 便可在尝试对保护空间进行身份验证之前检查它。通过返回 true，代理指示它可以处理身份验证，在对 connection(_:didReceive:) 的后续调用中它也确实这样做了。如果您的代理未实施此方法且保护空间使用客户端证书身份验证或服务器信任身份验证，系统将会尝试使用用户的密钥链来验证哪些可能不是所需的行为。

应用程序实施 NSURLConnection 或 NSURLSession 回调以处理身份验证请求。如果忘记确保身份验证请求来自于预期主机，凭证会发送到应用程序所加载的每个 URL。此外，如果无法检查是否能安全发送凭证，则会导致凭证被盗。

示例 1：以下应用程序将用户凭证发送到请求进行身份验证的任何主机：

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

tx.origin 全局变量保存发起交易的帐户地址。

如果智能合约 S1 从帐户 A1 收到交易，然后 S1 调用另一个智能合约 S2，然后在 S2 内部，tx.origin 包含帐户 A1 的地址，用于调用 S1。如果 tx.origin 的意图是验证 A1 的授权，那么将绕过此授权。

现在，如果攻击者可以诱骗用户将交易发送到恶意合约，然后该合约调用易受攻击的合约，在这种情况下用户通过 tx.origin 获得授权，然后 tx.origin 将保存发起交易的用户帐户的地址，并且将绕过授权。

示例 1：以下代码要求合约所有者（之前在构造函数中设置）与 tx.origin 相同，然后才能将资金转到提供的地址。

如果攻击者能够诱骗合约所有者将交易发送到恶意合约，该合约将立即调用易受攻击的合约中的 sendTo 函数，然后 require 语句中的条件将为 true，并且会将资金转到攻击者合约在调用 sendTo 时指定的任何地址。

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

宽松的访问配置会无端暴露系统并扩大组织的攻击面。向公众开放的服务通常会受到恶意实体近乎持续的扫描和探测。

当发现并发布某项公开服务的零日漏洞（例如 Heartbleed）时，尤其容易出现问题。攻击者可能会主动追踪和搜索未修补和暴露的系统以进行利用。

示例 1：以下 Ansible 任务定义了对外开放 TCP 端口 22 的 AWS 安全组 (0.0.0.0/0)，其中 SSH 服务器通常响应传入的连接请求。

- 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

Lambda 主体的通配符配置违反了最小特权原则，并使攻击者能够从任意帐户调用 lambda。

示例 1：以下示例 Ansible 任务定义了一个通配符 lambda 主体。

- 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