Live data from Hacker News

Web Security is Too Hard

textslashplain.com

51–60 of 127 posts

Re: Web Security is Too Hard

#51

Earlier quoted context omitted.

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.

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

I mean, it sounds like they're already doing that, just with extra downside

Re: Web Security is Too Hard

#52

What a ride of a read. I was 100% it was phishing and I got really surprised to find out it wasn't.

I only realized it wasnt after googling for the phrase “cloudflare.pay” and finding the announcement on Cloudflare’s own blog, which I trust because it is on cloudflare.com

All the bots including Google’s say it’s a phishing scam site probably, since they don’t know Cloudflare has a wallet product.

Re: Web Security is Too Hard

#53
post #43

Earlier quoted context omitted.

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.

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

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?

Re: Web Security is Too Hard

#54

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…

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

Re: Web Security is Too Hard

#55
post #11

In the movie Sneakers, a whole scene is taken up sending some guy on a date with Mary McDonnell so she could record clips of his voice. Today she'd just need a phone call or his Instagram. It's getting harder to keep up with who _people_ are online, much less organizations and domain names. Identity is hard y'all.

I don't understand what your point is. Do you disagree with any of the concrete suggestions in the blog post about what should have been done differently, or do you think they're hard to follow?

Re: Web Security is Too Hard

#56
post #48
post #28

Earlier quoted context omitted.

If you have no training or knowledge-base to search, sure. But then you'd be an awful support-team employer.

I mean, yes? That sounds pretty accurate for most companies before chatbots became the new hot thing

Uninformed chatbot replaces uninformed person. And the chatbot doesn't need bathroom breaks or health insurance.

Re: Web Security is Too Hard

#57

Earlier quoted context omitted.

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

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.

One example: a subdomain like experiment.example.com can access cookies for example.com.

Re: Web Security is Too Hard

#58

Earlier quoted context omitted.

You really would think that at least in theory a company like Cloudflare would make it very easy for internal teams to automatically request new subdomains

Running marketing off a separate domain is often a conscious decision because if they start getting blocked for spam, then critical service/operational emails from your actual domain might also get blocked.

Oh good, I'm glad that Cloudflare, proud defender of internet security, is properly focused on the important goal of optimizing for their ability to send promotional emails to my inbox rather than silly things like helping prevent phishing attacks.

Re: Web Security is Too Hard

#60
post #43

Earlier quoted context omitted.

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.

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

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.
Post reply on HN