An AWS IAM Principal defines access to a resource for a user, service, or other entity. In an IAM Statement, there is a definition of an IAM Principal that allows everyone to access an S3 action.

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain. Historically, web browsers have restricted their domain resources from being accessed by scripts loaded from a different domain to abide by the same origin policy.
CORS provides a method for a domain to allow other domains and enable them to access its resources.

Be careful when defining a CORS policy because an overly permissive policy configured at the server level for a domain or a directory on a domain can expose more content for cross domain access than intended. CORS can enable a malicious application to communicate with a victim application inappropriately, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.

Implementing CORS can increase an application's attack surface and should only be used when necessary.

Example 1: The following example template defines an overly permissive CORS policy for an Azure SignalR web application.

resource example 'Microsoft.SignalRService/SignalR@2022-02-01' = {
    ...
    properties: {
        ...
        cors: {
            ...
            allowedOrigins: [ '*' ]
        }
    }
}

Example 2: The following example template defines an overly permissive CORS policy for an Azure web application.

resource example 'Microsoft.Web/sites@2020-12-01' = {
    ...
    properties: {
        ...
        siteConfig: {
            ...
            cors: {
                ...
                allowedOrigins: [ '*' ]
            }
        }
    }
}

Example 3: The following example template defines an overly permissive CORS policy for an Azure Maps account.

resource example 'Microsoft.Maps/accounts@2021-12-01-preview' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Example 4: The following example template defines an overly permissive CORS policy for an Azure Cosmos DB account.

resource example 'Microsoft.DocumentDB/databaseAccounts@2023-04-15' = {
    ...
    properties: {
        ...
        cors: [
            {
                ...
                allowedOrigins: '*'
            }
        ]
    }
}

Example 5: The following example template defines an overly permissive CORS policy for an Azure storage blob service.

resource example 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
    ...
    properties: {
        ...
        cors: {
            corsRules: [
                {
                    ...
                    allowedOrigins: [ '*' ]
                }
            ]
        }
    }
}

Custom Azure subscription owner roles provide unrestricted access to all resources under the subscription, greatly increasing the exposure of the organization to risk and violating the least privilege principle.

Example 1: The following example shows a custom owner role definition with all possible privileges.

resource example 'Microsoft.Authorization/roleDefinitions@2022-04-01' = {
    ...
    properties: {
        ...
        permissions: [
            {
                ...
                actions: [ '*' ]
            }
        ]
    }
}

Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows(R) API. Most of these functions are vulnerable to various forms of attacks.
Example: The following code uses a temporary file for storing intermediate data gathered from the network before it is processed.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems.

Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant. See the Recommendations section for information about safe core language functions and advice regarding a secure approach to creating temporary files.

The functions designed to aid in the creation of temporary files can be broken into two groups based on whether they simply provide a filename or actually open a new file.

Group 1 - "Unique" Filenames:

The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess.

If a file with the selected name is created, then depending on how the file is opened the existing contents or access permissions of the file may remain intact. If the existing contents of the file are malicious in nature, an attacker may be able to inject dangerous data into the application when it reads data back from the temporary file. If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions.

Finally, in the best case the file will be opened with a call to open() using the O_CREAT and O_EXCL flags or to CreateFile() using the CREATE_NEW attribute, which will fail if the file already exists and therefore prevent the types of attacks described previously. However, if an attacker is able to accurately predict a sequence of temporary file names, then the application may be prevented from opening necessary temporary storage causing a denial of service (DoS) attack. This type of attack would not be difficult to mount given the small amount of randomness used in the selection of the filenames generated by these functions.

Group 2 - "Unique" Files:

The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp().

The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker may pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance.

Finally, mkstemp() is a reasonably safe way to create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.

Mismanagement of permissions increases the risk of unauthorized access to or modification of restricted data.

To define user permission for access to buckets and objects in buckets, Google Cloud Storage offers two systems: Access Control Lists (ACLs) and Identity and Access Management (IAM). IAM can be used throughout Google Cloud, while only Cloud Storage supports ACLs. Enabling Uniform Bucket-level Access prevents ACLs from granting permission. This ensures IAM is the only system to manage all access control of Google Cloud resources.

Example 1: The following Terraform configuration permits using ACLs alongside IAM to grant access to the storage bucket by setting uniform_bucket_level_access to false.

resource "google_storage_bucket" "bucket-demo" {
...
  uniform_bucket_level_access = false
...
}

An attacker will be able to create a file in the server's file system with arbitrary contents. The file created could then be used later by the attacker in order to perform additional attacks, dependent on the ability to control the contents injected into the file.

If the attacker is capable of controlling the contents of the file and the file is served by a web server, then he will be able to inject a malicious web shell, which can let him execute arbitrary commands on the server remotely.

If the attacker may create the file with the contents from a different file in the file system, he will be able to read arbitrary files on the file system that can be accessed using the permissions of the vulnerable application.

Any class that inherits the StateHolder interface must implement both saveState(javax.faces.context.FacesContext) and restoreState(javax.faces.context.FacesContext, java.lang.Object) or implement neither of them. Because these two methods have a tightly coupled relationship, it is not permissible to have the saveState(javax.faces.context.FacesContext) and restoreState(javax.faces.context.FacesContext, java.lang.Object) methods reside at different levels of the inheritance hierarchy.

Example 1: The following class defines saveState() and not restoreState(), so it is always in error no matter what any class that extends
it might do.

public class KibitzState implements StateHolder {
  public Object saveState(FacesContext fc) {
    ...
  }
}