Azure blob container allows anonymous reads

Description

Allowing anonymous reads on an Azure blob container lets clients read data without authenticating. In Ansible, public_access: blob permits blob reads; public_access: container also permits listing blobs within that container. Neither setting grants anonymous writes.

The account's anonymous-access setting and network rules also determine whether requests succeed. Separate files intended for public distribution from private data, and keep anonymous reads disabled for private data.

Potential impact

• Anonymous reads of blobs that should be private can disclose documents, logs or uploaded files. Determine separately whether the files are intended for public distribution.
• The container level can also reveal file names and the organization of stored data.
• Applications that rely on anonymous reads can stop working after access is disabled. Prepare an appropriate authentication method for required clients before changing access.

Remediation

1. Identify the data and clients that need public access, and separate public distribution from private data. Consider a separate account for public distribution when protecting the rest of an account.
2. For an existing container, use Azure's access-level controls to disable anonymous access and verify the result. Omitting public_access in azure.azcollection 3.21.0 does not update an existing access level. Omit the option when creating a new private container; this module does not accept private as a choice.
3. If none of the account's blobs need anonymous access, set AllowBlobPublicAccess to false. This restriction does not cover the static website endpoint, so review sites using $web separately.
4. Grant required read permissions narrowly to authenticated users or applications, and review the scope and expiration of any SAS. After the change, verify that anonymous requests fail and required authenticated clients still work, taking network restrictions into account.

Examples

Anonymous read access

- name: Create container and upload a file
  azure_rm_storageblob:
    resource_group: myResourceGroup
    storage_account_name: clh0002
    container: foo
    blob: graylog.png
    src: ./files/graylog.png
    public_access: blob

Private access for a new container

- name: Create container and upload a file
  azure_rm_storageblob:
    resource_group: myResourceGroup
    storage_account_name: clh0002
    container: foo
    blob: graylog.png
    src: ./files/graylog.png
    content_type: application/image

Explanation:

• Anonymous read access: If a new container is created successfully and the account and network settings permit access, public_access: blob allows anonymous blob reads. In azure.azcollection 3.21.0, this task does not change an existing container's access level.
• Private access for a new container: A newly created container uses private access by default because the public-access option is omitted. If a public foo already exists, this code alone does not change its access level. Both examples assume an existing storage account, execution permissions and a local file. Adding content_type does not restrict access permissions.

References

• CWE-284
• Ansible azure.azcollection.azure_rm_storageblob documentation
• Container creation and update implementation in azure.azcollection 3.21.0
• Azure anonymous reads and account settings
• Preventing anonymous access and assessing client impact
• Read and listing permissions at each container access level