Hacker News Reader

Comment by wheaties | Hacker News Reader

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.

View on HN

Please 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.

Or use CloudFront with an S3 bucket as backing for this use case, like you'd expect? CloudFront has domain name verification.

The 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).

The 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.

Whether 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.

I take it back. S3 outlines this exact use case: https://docs.aws.amazon.com/AmazonS3/latest/userguide/IndexD...

Because of this, I agree, they should verify domain ownership to help protect their users.

I'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.

Reply on news.ycombinator.com