The application implements the NSURLConnection or NSURLSession callbacks to handle authentication requests. Forgetting to ensure that the authentication request comes from the expected host would result in credentials being sent to every URL the application loads. In addition, failing to check that the credentials can be sent securely would result in credentials being stolen.

Example 1: The following application sends user credentials to any host asking for authentication:

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

The tx.origin global variable holds the address of the account from where a transaction originates.

If a smart contract, S1, receives a transaction from an account, A1, and then S1 calls another smart contract, S2, then inside S2, tx.origin contains the address of account, A1, used for calling S1. If the intent of tx.origin is to verify authorization of A1, then this authorization is bypassed.

Now, if an attacker can trick a user into sending a transaction into a malicious contract that them invokes the vulnerable contract where the user is authorized via tx.origin, then tx.origin will hold the address of the user account that initiated the transaction and authorization will be bypassed.

Example 1: The following code requires the owner of the contract (previously set in the constructor) to be the same as tx.origin before transferring funds to a provided address.

If an attacker is able to trick the owner of the contract into sending a transaction to a malicious contract which immediately calls the sendTo function in the vulnerable contract, then the condition within the require statement will be true and funds will be transferred to whatever address the attacker contract specified when calling sendTo.

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

Loose access configurations unnecessarily expose systems and broaden an organization's attack surface. Services open to interaction with the public are typically subjected to near continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following Ansible task defines an AWS Security Group that opens to the world (0.0.0.0/0) the TCP port 22, where an SSH server typically responds to incoming connection requests.

- 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

A wildcard configuration for lambda principals violates the least privilege principle and allows an attacker to invoke the lambda from any account.

Example 1: The following example Ansible task defines a wildcard lambda principal.

- 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

Amazon Redshift clusters are by default not publicly accessible.

Enabling public access to a cluster results in a wider attack surface for the organization.

Example 1: The following example shows an Ansible task that explicitly enables public access to an Amazon Redshift cluster by setting the publicly_accessible parameter to yes.

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

A misconfiguration of public access to an S3 bucket is a leading cause of data breaches.

Although S3 buckets block public access by default, any authorized user can update bucket policies or access control lists (ACLs) to allow public access.

An Amazon EC2 AMI that maps an unencrypted block device exposes the data to unauthorized access and potential theft.

Example 1: The following Ansible task creates an Amazon EC2 AMI and attaches a block device without data at rest encryption to the AMI because the encrypted parameter is set to 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