81–90 of 199 posts
Recently 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…
Earlier quoted context omitted.
Thanks, I’ve seen scripted attacks bypass this sort of hidden input unfortunately (perhaps human assisted or perhaps just ignoring hidden fields).
They often do actually ignore truly hidden fields (input type=hidden) but if you put them "behind" an element with css, or extremely small but still rendered, many get caught. It's similar to the cheeky prompt injection attacks people did/do against LLMs.
Earlier quoted context omitted.
So your solution would be to do nothing? Cloudflare is an excellent solution for many things. The internet was designed to withstand a nuclear war, but it also wasn’t designed for the level of hostility that goes on on the internet these days.
Cloudflare is not the solution
> While the victim is drowning [...] the attacker is doing something else.
In the past months some personal mail accounts on a mail server I administer were victim of something that looked similar to what's described here.
Hundreds of mails apparently originating from various (legit-looking) random public web services, support requests, issue trackers, web contact forms etc. For example, a good part of them was from Virginia Department of Motor Vehicles (as in something like "thank you for filing a document #123 with us").
To make things even weirder, they were not sent directly to the address, but according to message headers were bounced through Google Groups (each time I checked the relevant group was already deleted). So as far as I can tell it was not the mail address hosted on my server that was being entered into those websites.
No phishing links, no attached malware, no short advertisements snuck into a text field etc. Just a huge amount of automated replies from "noreply@" legit entities.
I've seen several of these attacks and spent some time investigating them. To my knowledge these were not associated with any other malicious activity, like the author of the article mentions. If anything they were just a denial-of-service attack on a mail box (as in, making the human user trawl through garbage, the mail volume was far from saturating the server itself). What exactly would be a motivation for that I can't tell, except making the life of a small mail server admin even harder than it already is.
Earlier quoted context omitted.
How about a signup flow where the user sends the first email? They send an email to signups@example.com (or to a generated unique address), and receive a one-time sign-in link in the reply. The service would have to be careful not to process spoofed emails though. Another approach is to not ask for an email address at all, like here on HN.
"The user just needs to be careful not to step on a landmine. Exact steps left as an exercise to the reader". Anybody can send email with all of the dmarc stuff, how do you "be careful" with spoofed email?
You actually verify DKIM and SPF—you know, that “dmarc stuff”. That’s enough to tell you the mail is not spoofed.
Now, every mofo just wants a grant to ---- innocent kids in school.
Earlier quoted context omitted.
Can you expand on that? A separate honey pot sign up page invisible to real users, or something else?
You add "hidden" inputs to your HTML form that are named like "First Name" or "Family Name". Bots will fill them out. You will either expect them to be empty or you fill by JavaScript with sth you expect. It's of course reverse-engineerable, but does the trick.
Earlier quoted context omitted.
And your solution is assume everyone on the internet is a good actor? How would you solve this at scale?
How about a signup flow where the user sends the first email? They send an email to signups@example.com (or to a generated unique address), and receive a one-time sign-in link in the reply. The service would have to be careful not to process spoofed emails though. Another approach is to not ask for an email address at all, like here on HN.
Every extra field in the sign-up form already lowers the conversion rate.
Recently 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…
JS can be reversed, you clearly see what data points they use for detection. Anything can be spoofed and it will look like human behavior.
And if everything fails, you outsource it to AI - Always Indian :D