3 ms·
Cloudflare is not the solution
by sdevonoes 6mo ago
Cloudflare is not the solution
- stingraycharles 6mo agoWhat is a better solution?
- sarchertech 6mo agoYou have to think hard about the problem and apply individual solutions. Cloudflare didn’t work for the author anyway. Even if they had more intrusive settings enabled it would have just added captchas, which wouldn’t likely have stopped this particular attacker (and you can do on your own easily anyway). In this case I assume the reason the attacker used the change credit card form was because the only other way to add a credit card is when signing up, which charges your card the subscription fee (a much larger amount than $1). So the solution is don’t show the change card option to customers who don’t already have an active (valid) card on file. A more generic solution is site wide rate limiting for anything that allows someone to charge very small amounts to a credit card. Or better yet don’t have any way to charge very small amounts to cards. Do a $150 hold instead of $1 when checking a new card As far as cloudflare centralization goes though, you’re not going to solve this problem by appealing to individual developers to be smarter and do more work. It’s going to take regulation. It’s a resiliency and national security issue, we don’t want a single company to function as the internet gatekeeper. But I’ve said the same about Google for years.
- HumanOstrich 6mo agoNone 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 an alert that in the past few hours or days even, 90% of card change attempts have failed for a cluster of users.
- withinboredom 6mo agoA $150 hold would clearly be noticed by the victim, so the attacker wouldn't even try it.
- dpkirchner 6mo agoMaybe if my bank emailed me, otherwise I doubt it. Local gas stations routinely use $200 holds and I'd have to go way out of my way to see it happen.
- sarchertech 6mo agoThe point is whether every user actually notices it, it's that enough of them do that attackers are specifically looking for the ability to do small charges. If you remove that capability, they will look elsewhere.
- scott_w 6mo agoYeah… 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.
- sarchertech 6mo agoThere's a reason attackers exploit any site that lets them do small charges, it's because enough users will notice a larger charge. Whether every user notices it or not, attackers are looking for the ability to do small charges, and if you remove that they'll move on.
- sarchertech 6mo ago>None of your solutions seem useful in this case, especially a $150 hold. Attackers are going after small charges. That's the reason they're going after these guys in the first place. >Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up. And then you give a solution that is 10x as 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. This is essentially a much more complex superset of rate limiting.