[flagged]
Subscription bombing and how to mitigate it
161–170 of 199 posts
Re: Subscription bombing and how to mitigate it
#162Earlier quoted context omitted.
None of your solutions seem useful in this case, especially a $150 hold. Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up. You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes. Combine that with other (useful) mitigations. Maybe getting…
A $150 hold would clearly be noticed by the victim, so the attacker wouldn't even try it.
Yeah… no it wouldn’t. I’ve watched users have their bank accounts emptied (by accident) because they kept refreshing. A measly £150 isn’t going to register until it’s too late anyway.
Re: Subscription bombing and how to mitigate it
#163Earlier quoted context omitted.
the "notice unusual behavior" is the hard part
thousands of $1 charges and refunds in a 7 hour period seems unusual to me. then again, i've never run a site that received thousands of charges ever, so seeing it in a few hours would be obvious.
Genuinely asking, are you a product manager? You’re giving me flashbacks to all of the PMs who suggested a 2-3 branch decision tree for a complex classification problem, because that’s what struck them as intuitive. We are just a few baby steps away from reinventing the entire field of fraud detection within this thread.
Re: Subscription bombing and how to mitigate it
#164Earlier quoted context omitted.
Ouch. Just one credit card change per account? This is one of those levels of monitoring that only gets put in place after such an event. Eg whole subsystem analysis - the change card feature being used 1000s of times (well, proportional to scale) in 7 hours is a massive red flag
> This is one of those levels of monitoring that only gets put in place after such an event. For a website, yes. But honestly the credit card people and their infrastructure should probably _also_ watch out for this. They'd be in a much better place to detect these.
In a perfect world sure but in the real world if a processor catches something they will disable your processing and freeze any funds while making it a nightmare to remedy, so you really want them doing as little as possible.
Re: Subscription bombing and how to mitigate it
#165One thing I have never understood in this current age is how in the world so many companies, including ones that handle confidential data like banks, don’t require a user to verify their email address after it’s entered. I have an unfortunately very generic email address that’s easy to mistype, and I am almost every day receiving order receipts for expensive vacation hotels, bank transfer or wire transfer confirmatio…
I get this stuff all the time. Once, I got the information someone requested about a drug company helping cover the cost of a drug for a lower-income individual (who was apparently the one who mistyped his email address). It included his name, city, and some other personal information. The drug was only approved for one medical issue. Total HIPAA/HITECH violation.
They didn’t have a HIPAA coordinator by title, so I got to explain how to avoid this to their legal department.
Re: Subscription bombing and how to mitigate it
#166Mitigating this is kind of pointless, because so many sites are vulnerable to this.
I got subscription bombed from about a dozen .gov sites a while back. Healthcare.gov, Social Security Administration, WTC Health Program, FDA, National Institute of Mental Health, Medicare.gov.
It's very easy for attackers to do this. Putting in effort to solve this for one site, and expecting any impact, is like trying to empty the ocean with a teaspoon.
Re: Subscription bombing and how to mitigate it
#167Recently we suffered a different kind of subscription bombing: a hacker using our 'change credit card' form to 'clean' a list of thousands credit cards to see which ones would go through and approve transactions. He ran the attack from midnight to 7AM, so there were no humans watching. IPs were rotated on every single request, so no rate limiter caught it. We had Cloudflare Turnstile installed in both the sign up for…
We had this happen on one of our sign up forms. I added a crappy open source image captcha and it went away. I guess whichever attacker was using us wasn't that motivated!
Re: Subscription bombing and how to mitigate it
#168Earlier quoted context omitted.
thousands of $1 charges and refunds in a 7 hour period seems unusual to me. then again, i've never run a site that received thousands of charges ever, so seeing it in a few hours would be obvious.
Genuinely asking, are you a product manager? You’re giving me flashbacks to all of the PMs who suggested a 2-3 branch decision tree for a complex classification problem, because that’s what struck them as intuitive. We are just a few baby steps away from reinventing the entire field of fraud detection within this thread.
Sir, I resent the implication! I do not lie with such swine!
It's easy to say that every site must add protections against every single type of attack, except it's impossible for site owners to be experts in fraud. While credit card processing vendors are expected to be experts in fraud. I ask you where in this situation would be the better place to implement fraud detection? Of the two places, whose more financially at risk?
Re: Subscription bombing and how to mitigate it
#169As a newsletter company, we've dealt with this for over a decade now since we do the right thing and do double opt-in which involves sending the subscriber an email on signup. Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs,…
That's a fun cobra effect. Age verification ("intended" to make children safer online, if you take the most charitable view) forces more and more people to use VPNs, which overall degrades the value of IP reputation as a signal, forcing providers to accept less reputable IPs because real customers come from them, which means that providers are more vulnerable to attacks that can be used to target children.
Re: Subscription bombing and how to mitigate it
#170Earlier quoted context omitted.
Honestly I really like CloudFlare as a business. There's no vendor lock-in, just a genuine good product. If they turn around later and do something evil, literally all I need to do is change the nameserver to a competitor and the users of my website won't even notice.
Then you're not using any of their services besides DNS, at which point you don't need to use Cloudflare at all. As soon as you turn on any other service they offer, you need to actively migrate away. It's an inherent issue of services that actually provide a benefit. If you're saying "I can just migrate to any other nameserver" then you're telling me you have no use for Cloudflare in the first place. Because if you…
I use their DNS and also their proxy.
Both are extremely useful and good products.
I assumed this is what GP was talking about when referring to the turnstile.