XEIZE
/Vulnerability documentation/IaC/Terraform/Alibaba Cloud/OSS bucket policy combines wildcard principals with put actions

OSS bucket policy combines wildcard principals with put actions

Restrict OSS upload and configuration permissions to required principals to prevent unwanted content and operational changes.

Description

Granting OSS upload or configuration actions to all principals can let untrusted principals store data or change settings when suitable access restrictions are absent. Effective permissions depend on the actions, target resources, conditions, explicit denies, and Block Public Access.

PutObject uploads objects, while other Put operations can change configuration. Restrictions differ by operation. For example, PutObjectACL is limited to the bucket owner with read and write permissions on the object; specifying a wildcard principal does not let everyone change an existing object's ACL.

Potential impact

  • If principals that do not need upload permission receive effective upload permission, they may add unwanted objects and increase storage costs.
  • Writes to an existing object name can change the content an application reads. Enabling versioning still allows the current version to change; this does not mean that previous versions are deleted.
  • Effective permission to change configuration can alter access controls or other operational settings. Check each action's ownership and permission restrictions.

Remediation

  • Limit principals and actions for uploads and configuration changes, and specify the bucket or object resource paths appropriate to each operation. Do not grant public writes merely to support public reads.
  • Review conditions, explicit denies, ACLs, and Block Public Access together, including each API's ownership and permission requirements. A private ACL does not block all policy-based access.
  • Inline policy has been deprecated since provider 1.220.0. Manage new configurations with alicloud_oss_bucket_policy, and verify required uploads and access restrictions after migrating an existing policy.

Examples

These examples use the legacy inline policy form supported in provider 1.293.0. Choose an available, unique bucket name and update the object paths to match. Both examples assign permissions to all principals and should not be applied unchanged in production.

Upload and object ACL permissions

hcl
resource "alicloud_oss_bucket" "bucket-policy4" {
  bucket = "bucket-4-policy"
  acl    = "private"

  policy = <<POLICY
  {"Statement": [
    {
        "Action": [
            "oss:PutObjectAcl", "oss:PutObject"
        ],
        "Effect": "Allow",
        "Principal": [
            "*"
        ],
        "Resource": [
            "acs:oss:*:*:bucket-4-policy/*"
        ]
    }
  ],
   "Version":"1"}
  POLICY
}

Restrict uploads to required accounts or roles and narrow the object paths to what they need. oss:PutObjectAcl has separate ownership and permission requirements and should not be granted solely to allow uploads.

Multipart upload cancellation permission

hcl
resource "alicloud_oss_bucket" "bucket-policy1" {
  bucket = "bucket-1-policy"
  acl    = "private"

  policy = <<POLICY
  {"Statement": [
    {
        "Action": [
            "oss:AbortMultipartUpload"
        ],
        "Effect": "Allow",
        "Principal": [
            "*"
        ],
        "Resource": [
            "acs:oss:*:*:bucket-1-policy/*"
        ]
    }
  ],
   "Version":"1"}
  POLICY
}

Given a valid upload ID and the required permission, oss:AbortMultipartUpload cancels a multipart upload and deletes its uploaded parts. It does not delete a completed object, but it can interrupt uploads, so restrict it to the operational principals that need it.

References

XEIZE DocumentationTechnical support