| ▲ | epochbtc 2 hours ago |
| Ironically, this might be at least partially because the internal security controls at Cloudflare for using or provisioning new domains/subdomains is so difficult and arduous that the team decided the fastest way to go to market is to get an entirely new domain. Possible bonus that the official bug bounty program won't apply either, since it's on a new domain so any vulnerabilities found won't have to be paid out (as much). |
|
| ▲ | OkayPhysicist an hour ago | parent | next [-] |
| Why is this so, so common? They're subdomains. They're free. It's not hitting anybody's budget to publish a new DNS entry. If someone has permission to publish anything in your name, they probably should be able to go make themselves a subdomain. |
| |
| ▲ | edent an hour ago | parent | next [-] | | Because they point foo.example.com to AWS. They then let whatever the CNAME is pointing to lapse. Then an attacker registers the lapsed AWS and can now put their content on your trusted domain. https://aws.amazon.com/blogs/security/threat-tactic-spotligh... (AWS have since fixed this problem, but it exists on other services.) | | |
| ▲ | saghm 37 minutes ago | parent | next [-] | | So the solution is to make it even easier to let the domain records lapse by putting it outside the place where everyone would know about it, with the added bonus that now you can super easily let the domain registration itself lapse without noticing so that your customers who have been told to use it can get directly pwned by whoever grabs it? | |
| ▲ | chrisandchris 29 minutes ago | parent | prev [-] | | Which you could mitigate by using a Cert-Policy in DNS and HTST, so an attacker might not get s valid certificate for your domain and at least access is sonewhat restricted. |
| |
| ▲ | epochbtc an hour ago | parent | prev [-] | | Counter-argument is: do you really want some team of 90% marketers and PMs throwing up a MVP/WIP codebase for some ancillary product not related to your core business on your core domain? At a minimum you'd want a thorough security review and risk assessment, and that goes against the ethos of "ship fast and pivot as needed". | | |
| ▲ | ryandrake an hour ago | parent | next [-] | | Why does the TLD matter in this case? How does your security/risk posture change if you launch on myexperiment.mycompany.com vs. www.mycompanyexperiment.website that you had to go out and newly purchase? Asking because I legit don't know. | | |
| ▲ | nvme0n1p1 31 minutes ago | parent [-] | | One example: a subdomain like experiment.example.com can access cookies for example.com. |
| |
| ▲ | saghm 44 minutes ago | parent | prev [-] | | I mean, it sounds like they're already doing that, just with extra downside |
|
|
|
| ▲ | AndrewKemendo 36 minutes ago | parent | prev [-] |
| I’d argue this is exactly why this happened and why the poster is correct but missing the point: Your organizational management is the problem not the technology If you can’t coordinate internally to roll out a proper domain then I question how well your teams are managed |
