4 ms·
This should be something added to an AWS Security Hub check, e.g. do you have Route53 pointed to an unregistered domain. Otherwise, I can't find fault with AWS
by wheaties 5y ago
This should be something added to an AWS Security Hub check, e.g. do you have Route53 pointed to an unregistered domain. Otherwise, I can't find fault with AWS at all. Now I have to review our domains on Monday.
- toomuchtodo 5y agoPlease bug your TAM if you have one about this. I’ve bugged ours. S3 should not serve a bucket as a website without domain verification. In the interim, we’ve built middleware where a bucket serving content can’t be removed until the dns record has been.
- ctvo 5y agoOr use CloudFront with an S3 bucket as backing for this use case, like you'd expect? CloudFront has domain name verification.
- manigandham 5y agoThe point is that without domain verification, it won't stop someone else from registering that bucket (which is what happened with the domains in this article).
- ctvo 5y agoThe point is that S3 isn't a CDN. If you use it as a CDN, it's on you to ensure it'll work for your use case. CloudFront, however, is a CDN, and as expected, has domain verification.
- manigandham 5y agoWhether it's a CDN is irrelevant. This is already a supported use-case for S3 which is why it even has this functionality. It's one of many products that supports serving under custom hostnames and all such products should have domain verification.
- ctvo 5y agoI take it back. S3 outlines this exact use case: https://docs.aws.amazon.com/AmazonS3/latest/userguide/IndexDocumentSupport.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/IndexD... Because of this, I agree, they should verify domain ownership to help protect their users.
- phamilton 5y agoI've seen this attack with cloudfront and an S3 bucket. You can verify your domain is going to a cloudfront you own, but it doesn't verify that the origin is a bucket you own.