cloud-s3-exposurelisted

# Cloud object-storage misconfiguration ## When it applies The app stores files in S3/GCS/Azure Blob and the bucket's ACL/policy is too open — public listing, public read of private objects, or (worst) unauthenticated write. ## Why it works Object-storage ACLs are easy to get wrong: "public" gets applied at the bucket level, or an IAM policy grants `s3:ListBucket`/`GetObject`/`PutObject` to `*`. Predictable names (`companyname-backups`, `-assets`, `-dev`) make discovery trivial. ## Method 1. **Find bucket names**: from asset URLs, JS, DNS CNAMEs, and permutations of the org name (`company`, `company-prod`, `company-backups`, region suffixes). 2. **Test list/read (S3)**: `aws s3 ls s3://bucket --no-sign-request` (list) and `aws s3 cp s3://bucket/file . --no-sign-request` (read). `--no-sign-request` = anonymous. 3. **Test write** (high impact, do carefully & in scope): `aws s3 cp poc.txt s3://bucket/ --no-sign-request` — a successful anonymous write is critical (defacement/malware hosting). 4. **GCS/Azure**: `gsutil ls gs://bucket` / anonymous HTTPS `GET`; Azure `?comp=list` on the container. 5. **Scale carefully** with `s3scanner`/`gcpbucketbrute` on name lists — respect scope & rate. ## Gotchas - 403 on the bucket root ≠ safe — individual objects may still be public; test known object paths. - Anonymous write is the crown jewel but easy to over-test — upload one harmless marker, then stop. - Region matters for the endpoint; a wrong region gives misleading 301/403