What You See Is Not What You Get: Weird Behaviors in S3 Bucket Policies (github.com) 2 points by elfakyn 5y ago ↗ HN
[–] elfakyn 5y ago ↗ I wrote this up since, over the past year, I've encountered more and more weird behavior with s3 bucket policies.I haven't seen all of this behavior documented in a single place, so here it is.Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.A TL;DR of the security stuff:* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.
1 comment
[ 0.27 ms ] story [ 9.4 ms ] threadI haven't seen all of this behavior documented in a single place, so here it is.
Some of it has security implications (such as being able to brute force usernames) that is worth knowing about.
A TL;DR of the security stuff:
* Brute-forcing valid principal names is possible, since you can't create a bucket policy with an invalid principal.
* User compromise will break cross-account access, since if AWS becomes aware of a compromise, they will want you to delete the user and recreate it.
* Explicit denies will stop working if the principal is deleted and recreated, since they operate internally on the Principal ID and not the ARN
* Canonical IDs offer no extra security compared to account ARNs, since it's trivial to convert them back and get an account number.