4 ms·

Google provides several options for site verification. They provide a string you must place on your website using one of the following ways: - DNS TXT record

by moltar 5y ago

Google provides several options for site verification. They provide a string you must place on your website using one of the following ways: - DNS TXT record - HTML meta tag - Upload a file with a randomized name to your site root

ctvo 5y ago
This is the reverse situation. What's going on here: - Bob makes bob.com and sets the CNAME to be bobstaticsite.s3.aws - Bob forgot to make a bucket called bobstaticsite.s3, and Alice, scanning the DNS records, creates it instead. Now Alice is serving data on Bob's domain Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility? Don't make that CNAME entry pointing to a bucket you didn't create yet / don't own? One final thing: S3 is not CloudFront. And CloudFront, AWS's CDN, does require domain name verification.
- detaro 5y ago
  AWS can't stop you from creating the CNAME, but AWS could stop Alice from creating the bucket, or (IMHO better) not serve HTTP(S) traffic for bob.com from that bucket unless it is confirmed that the bucket belongs to the owner of bob.com.
  - chaboud 5y ago
    Could Eve then just register bob.com and point it to bob's random bucket to mess with him? And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? It seems like the answer already exists: don't create CNAMEs haphazardly. (But please explain it to me if I'm missing something here)
    - detaro 5y ago
      > Could Eve then just register bob.com and point it to bob's random bucket to mess with him? If it blocks creation, she would have to know the bucket name Bob would want to create soon. At which point she could just create the bucket instead. > And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? She can only do that with this method if Bob's bucket is called "alice.com". Doesn't seem important to support for random unrelated people, if its for a dedicated setup where Bob manages a thing for Alice you could always have a way of granting that permission specifically or to opt out of the verification. > It seems like the answer already exists: don't create CNAMEs haphazardly. "don't make mistakes". If people keep making a mistake all the time, that's not the greatest answer. There's a reason most other providers that allow you to point a domain at them do some verification.
      - chaboud 5y ago
        How would it block creation? Is AWS supposed to keep a full record of CNAME entries for the Internet and keep it up to date? Since CNAME records can point to other domains, I’m not sure how AWS is supposed to police this and allow cross-referencing from other parties. Blocking based on any CNAME presence could turn into a bucket-squatting exploit pretty quickly. A CNAME record is an “I’m pointing my domain at some other place” record. Redirect to something out of your control, S3 or otherwise, and you’re handing over control of the returned content. That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
        detaro 5y ago
        yes, as mhio already pointed out the first variant doesn't actually work. The second does though, and is what's commonly done. > That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work. "I hold something into a saw, and it gets cut. That doesn’t so much strike me as a mistake but more as the way that saws are supposed to work. Why are all these fingerless people saying our saws should have safety features?!" We know such things happen to all kinds of people all the time. It has been part of actual security problems. We know how to fix it, because many service providers do require validation. Why not consider the validation?
        chaboud 5y ago
        You’ve tried the snark twice, but it’s not aiding your point. What is the actual mechanism you think should be implemented, and how does that support cross-party referencing while avoiding other modes of vulnerability (e.g. denial of service)?
  - mhio 5y ago
    Amazon can't "know" out of all domains if one has a CNAME pointing to a bucket name though. Even if they did, that would be open to abuse by anyone.
    - detaro 5y ago
      derp, true. so only the second method works.
- elithrar 5y ago
  > Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility? They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven. This also helps avoid related cases, such as deleting a bucket (which now frees it up) - other services like Heroku have similarly been vulnerable to this takeover hack because of a lack of strict verification: https://0xpatrik.com/subdomain-takeover-providers/ https://0xpatrik.com/subdomain-takeover-providers/ Every new bucket, service or account handling traffic for a domain should require re-verification. That verification should never persist beyond the lifetime of that resource.
  - elcomet 5y ago
    > They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven. Why shouldn't they ? Don't you think it can be a useful feature ?
    - FlyingAvatar 5y ago
      The problem is that AWS only allows hosting domains on S3 that match the hostname. i.e. If I want to host some content from S3 on 'static.mydomain.com', I MUST own the bucket of the same name. If someone else creates the bucket on their AWS account, I am stuck. I would have to use a different hostname, or use a more complex workaround. Since creating empty buckets costs nothing, it effectively allows DoSing hostnames from an S3 hosting standpoint. It would be one thing to allow this behavior if a domain owner explicitly wanted it, via a TXT record or something, but as it is, it's a poorly designed solution.
bawolff 5y ago
All of which are much weaker than the CNAME, since with a cname you can do all 3.

by moltar 5y ago

ctvo 5y ago

This is the reverse situation. What's going on here: - Bob makes bob.com and sets the CNAME to be bobstaticsite.s3.aws - Bob forgot to make a bucket called bobstaticsite.s3, and Alice, scanning the DNS records, creates it instead. Now Alice is serving data on Bob's domain Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility? Don't make that CNAME entry pointing to a bucket you didn't create yet / don't own? One final thing: S3 is not CloudFront. And CloudFront, AWS's CDN, does require domain name verification.

detaro 5y ago
AWS can't stop you from creating the CNAME, but AWS could stop Alice from creating the bucket, or (IMHO better) not serve HTTP(S) traffic for bob.com from that bucket unless it is confirmed that the bucket belongs to the owner of bob.com.
- chaboud 5y ago
  Could Eve then just register bob.com and point it to bob's random bucket to mess with him? And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? It seems like the answer already exists: don't create CNAMEs haphazardly. (But please explain it to me if I'm missing something here)
  - detaro 5y ago
    > Could Eve then just register bob.com and point it to bob's random bucket to mess with him? If it blocks creation, she would have to know the bucket name Bob would want to create soon. At which point she could just create the bucket instead. > And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? She can only do that with this method if Bob's bucket is called "alice.com". Doesn't seem important to support for random unrelated people, if its for a dedicated setup where Bob manages a thing for Alice you could always have a way of granting that permission specifically or to opt out of the verification. > It seems like the answer already exists: don't create CNAMEs haphazardly. "don't make mistakes". If people keep making a mistake all the time, that's not the greatest answer. There's a reason most other providers that allow you to point a domain at them do some verification.
    - chaboud 5y ago
      How would it block creation? Is AWS supposed to keep a full record of CNAME entries for the Internet and keep it up to date? Since CNAME records can point to other domains, I’m not sure how AWS is supposed to police this and allow cross-referencing from other parties. Blocking based on any CNAME presence could turn into a bucket-squatting exploit pretty quickly. A CNAME record is an “I’m pointing my domain at some other place” record. Redirect to something out of your control, S3 or otherwise, and you’re handing over control of the returned content. That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
      - detaro 5y ago
        yes, as mhio already pointed out the first variant doesn't actually work. The second does though, and is what's commonly done. > That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work. "I hold something into a saw, and it gets cut. That doesn’t so much strike me as a mistake but more as the way that saws are supposed to work. Why are all these fingerless people saying our saws should have safety features?!" We know such things happen to all kinds of people all the time. It has been part of actual security problems. We know how to fix it, because many service providers do require validation. Why not consider the validation?
        chaboud 5y ago
        You’ve tried the snark twice, but it’s not aiding your point. What is the actual mechanism you think should be implemented, and how does that support cross-party referencing while avoiding other modes of vulnerability (e.g. denial of service)?
- mhio 5y ago
  Amazon can't "know" out of all domains if one has a CNAME pointing to a bucket name though. Even if they did, that would be open to abuse by anyone.
  - detaro 5y ago
    derp, true. so only the second method works.
elithrar 5y ago
> Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility? They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven. This also helps avoid related cases, such as deleting a bucket (which now frees it up) - other services like Heroku have similarly been vulnerable to this takeover hack because of a lack of strict verification: https://0xpatrik.com/subdomain-takeover-providers/ https://0xpatrik.com/subdomain-takeover-providers/ Every new bucket, service or account handling traffic for a domain should require re-verification. That verification should never persist beyond the lifetime of that resource.
- elcomet 5y ago
  > They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven. Why shouldn't they ? Don't you think it can be a useful feature ?
  - FlyingAvatar 5y ago
    The problem is that AWS only allows hosting domains on S3 that match the hostname. i.e. If I want to host some content from S3 on 'static.mydomain.com', I MUST own the bucket of the same name. If someone else creates the bucket on their AWS account, I am stuck. I would have to use a different hostname, or use a more complex workaround. Since creating empty buckets costs nothing, it effectively allows DoSing hostnames from an S3 hosting standpoint. It would be one thing to allow this behavior if a domain owner explicitly wanted it, via a TXT record or something, but as it is, it's a poorly designed solution.

bawolff 5y ago

All of which are much weaker than the CNAME, since with a cname you can do all 3.