My sign up form was abused to send spam. Is yours safe?(mzrn.sh)
mzrn.sh
My sign up form was abused to send spam. Is yours safe?
https://mzrn.sh/2023/03/03/never-include-user-input-text-in-welcome-emails/
57 comments
Removing user-controlled input indeed removes the incentive, but for reasons beyond my comprehension, our sign up form _still_ gets periodically blasted. Without additional countermeasures, our sending reputation would be at risk.
We apply a few strategies...
1. Require oauth-based sign up for gmail.com, hotmail.com, and live.com addresses. No emails sent until after authentication.
2. Drop obvious spam. If your name contains "http://" or "Whatsapp" or your User-Agent is "python-requests" than you get a 400.
3. Manual approval for suspicious sign ups. High Abuse IP DB scores, statistically unusual names, etc generate a help desk ticket that someone from our staff approves before an email is sent. Persistent bad actors are blocked by IP for 2 weeks.
4. Rate limiting by IP. This prevents bad actors from spamming our help desk.
All together this seems to have largely solved the problem... for now.
We apply a few strategies...
1. Require oauth-based sign up for gmail.com, hotmail.com, and live.com addresses. No emails sent until after authentication.
2. Drop obvious spam. If your name contains "http://" or "Whatsapp" or your User-Agent is "python-requests" than you get a 400.
3. Manual approval for suspicious sign ups. High Abuse IP DB scores, statistically unusual names, etc generate a help desk ticket that someone from our staff approves before an email is sent. Persistent bad actors are blocked by IP for 2 weeks.
4. Rate limiting by IP. This prevents bad actors from spamming our help desk.
All together this seems to have largely solved the problem... for now.
> than you get a 400.
When I did this, the spammers got more creative trying other ways to get through.
Now I return a 200, and the response looks identical to a successful signup.
The only difference is nothing actually happened on the backend.
When I did this, the spammers got more creative trying other ways to get through.
Now I return a 200, and the response looks identical to a successful signup.
The only difference is nothing actually happened on the backend.
So far all "my" spammers seem indescriminate. I have the feeling that our form is just another URL on a very very long list, and I see no evidence of adaptation.
If there was something of value (besides excellent software) behind the signup form maybe we would need different strategies.
If there was something of value (besides excellent software) behind the signup form maybe we would need different strategies.
Signup which looks like successful but blackholed is user hostile. Majority of web form spammer don’t even try to evade filtering - why bother when there are many web forms without validation. All signup spam I’ve ever seen in email was sent via forms which allows to enter longish text in the name field with ether url or email address or phone number. Reasonable validation of user entered fields used in signup emails should stop 99% of such spam.
> Signup which looks like successful but blackholed is user hostile
I only do it for things which are clearly not valid users.
I only do it for things which are clearly not valid users.
Ah, I got a phone call yesterday because a small company I ordered something with didn't know where to send the package.
I gave them an e-mail address that contained a "+". Apparently MondialRelay silently dropped their requests. They thought they had sent me multiple e-mails. I received none.
I hate that kind of silent failure mode.
I gave them an e-mail address that contained a "+". Apparently MondialRelay silently dropped their requests. They thought they had sent me multiple e-mails. I received none.
I hate that kind of silent failure mode.
Well that seems hostile on purpose. "You try holding us accountable for what we do with your email, punk? Shadowban for you!"
I'm so tired of these idiots. I've been slowly teaching various (non tech) co workers how to protect themselves and every time we get to email signups, I have to add a caveat about this only sometimes working, if the company has intelligent programmer.
This is the way
My sign up form for https://cubetrek.com was recently abused in the way described (and solved) in https://news.ycombinator.com/item?id=34865695
The way it goes is that an attacker got hold of e.g. an Amazon account and starts ordering stuff to his address. In order to prevent the victim from becoming suspicious, the attacker buries the Amazon emails in an avalanche of spam emails. So a bot was submitting the victims email address to my sign up form, my app sends out a verification email to the victim and being part of the distraction.
I solved the problem by adding a Captcha (https://www.cloudflare.com/products/turnstile/) to the form.
The way it goes is that an attacker got hold of e.g. an Amazon account and starts ordering stuff to his address. In order to prevent the victim from becoming suspicious, the attacker buries the Amazon emails in an avalanche of spam emails. So a bot was submitting the victims email address to my sign up form, my app sends out a verification email to the victim and being part of the distraction.
I solved the problem by adding a Captcha (https://www.cloudflare.com/products/turnstile/) to the form.
Interesting, any reason why you chose this over recaptcha?
Not the parent, but I'd avoid anything Google, they track users well enough elsewhere.
In that case, I think a simple proof-of-work would be enough. I also like the oauth solution mentioned elsewhere if a domain is supported.
Here's a thought: why not create a "mailto:" link so that users send a mail with the verification token instead?
In that case, I think a simple proof-of-work would be enough. I also like the oauth solution mentioned elsewhere if a domain is supported.
Here's a thought: why not create a "mailto:" link so that users send a mail with the verification token instead?
Yes, I'm not too big of a fan of Google. Plus (I don't really know how it works behind the scenes) the Cloudflare approach is a simple checkmark, so there's no annoying clicking of tiles with motorcycles in it...
Any ideas on how a simple proof-of-work could look like, also from the backend side?
Any ideas on how a simple proof-of-work could look like, also from the backend side?
A simple proof-of-work would use a hash function (sha or something like blake2, in javascript or webassembly, can be multiple rounds), plus a server-provided random seed. Append random data to the seed until the hash function matches a certain condition. Submit the data to the server for checking.
Something like that pseudo-C code:
The issue with that approach is that slower clients will take longer to solve the challenge, but it just needs to be prohibitely expensive (and slow) for the attacker to spam this, even if they have powerful machines. Botnets can sidestep the issue a bit by distributing computing, but this should still slow them down.
You could also ask for the client's best find after x seconds if it's low-powered, and check that it is reasonable (though that can be gamed). The difficulty can also be increased temporarily if there is a surge of requests.
Maybe we need some kind of "Internet weather forecast" to adjust captca difficulty across websites according to detected botnet activity?
for(i=0; i<INT_MAX; i++) {
output = hash(concat(server_provided_data, i));
if(check_output(output))
break;
The issue with that approach is that slower clients will take longer to solve the challenge, but it just needs to be prohibitely expensive (and slow) for the attacker to spam this, even if they have powerful machines. Botnets can sidestep the issue a bit by distributing computing, but this should still slow them down.
You could also ask for the client's best find after x seconds if it's low-powered, and check that it is reasonable (though that can be gamed). The difficulty can also be increased temporarily if there is a surge of requests.
Maybe we need some kind of "Internet weather forecast" to adjust captca difficulty across websites according to detected botnet activity?
Your solution is for mass spam. For this Amazon abuse it may suffice to send 20 messages.
It's true, I assumed there would be multiple targets, maybe that was misguided?
You probably can't use a single website to send those 20 messages (if it's well-designed with a cool down), as the recipient address is the same. So you need 20 different websites to send these.
What outgoing spam rate is acceptable, assuming you can't reach zero? 1 per 10 sec?
You probably can't use a single website to send those 20 messages (if it's well-designed with a cool down), as the recipient address is the same. So you need 20 different websites to send these.
What outgoing spam rate is acceptable, assuming you can't reach zero? 1 per 10 sec?
Wow. It’s unfortunate that so many programmers dedicate their time to breaking systems like this all for spam. It’s pathetic the lengths we have to go to protect even the most basic parts of systems like sign up forms.
I understand the "this is why we can't have nice things" sentiment.
On the other hand, it's a fascinating topic on a technical level and I wouldn't compare it to other system exploits that you may witness in real life of people taking advantage.
On the other hand, it's a fascinating topic on a technical level and I wouldn't compare it to other system exploits that you may witness in real life of people taking advantage.
Not much different from the advertising industry itself, which always tries to find new ways to exploit human psychology.
They just test correctness of your code for free. Now you don't have to hire testers.
I don't get why. Probably there are more efficient ways to send spam.
This lets you send from an established domain that google trusts.
In my app, users can create projects, and invite other users to their projects. The invite email contains the project's name. You can guess what happened next :-)
The spammer must have been quite determined -- for free accounts there is a limit of invited users, so their automation script had to send an invite, cancel the invite, send the next invite, cancel, and so on.
Fixed by adding more rate limits.
The spammer must have been quite determined -- for free accounts there is a limit of invited users, so their automation script had to send an invite, cancel the invite, send the next invite, cancel, and so on.
Fixed by adding more rate limits.
I reject posted data from open forms if there are any "http", "https" or "@" in the field.
These are all spams. The last valid case was when someone wanted to report a bug on a page from my site and want to include the URL of that page. But this case is so rare now a days. People can't differentiate the URL of a page from the page itself.
These are all spams. The last valid case was when someone wanted to report a bug on a page from my site and want to include the URL of that page. But this case is so rare now a days. People can't differentiate the URL of a page from the page itself.
I have to think that the recent trend of dimming or even hiding (Safari) the full URL of the page has contributed to people not understanding how URLs work.
I think the first time I read about this had to be.. 1999 or so? Funny to think that form to emails are still getting abused like this 20+ years later.
Around 2000 I fixed more than a few FormMail.pl on a freelance basis. I suspect it's still doable to be a specialized consultant focusing on nothing but spam prevention.
> Never include any user-input text in welcome emails, or any other type of emails triggered by submitting publicly accessible forms, where the receiver’s email address is part of the submitted data.
Isn't it better to validate input data? If you don't do it you can have bigger problems then sending spam, regardless if you use user input data into welcome emails or not.
It amazes me to see the kind of code at some startups. Such code would never pass manual testing when working for a software company. But likely it won't reach testing phase because it won't pass code reviews.
Isn't it better to validate input data? If you don't do it you can have bigger problems then sending spam, regardless if you use user input data into welcome emails or not.
It amazes me to see the kind of code at some startups. Such code would never pass manual testing when working for a software company. But likely it won't reach testing phase because it won't pass code reviews.
Maybe then they won't send user password? If they don't anything, then they don't send the password.
I once fixed a Contact Us form that allowed the recipient email address to be overwritten, so anyone could put their spam in the body and sent it to anyone via that form.
[deleted]
There was something I saw recently where a form was exploited to send emails.
I can't remember the details unfortunately, but it was something I never thought of.
They were sending weird/crazy unexpected strings.
Oh they were exploiting automated responses saw on Reddit webdev
https://www.reddit.com/r/webdev/comments/10ujhh4/why_do_i_ge...
I can't remember the details unfortunately, but it was something I never thought of.
They were sending weird/crazy unexpected strings.
Oh they were exploiting automated responses saw on Reddit webdev
https://www.reddit.com/r/webdev/comments/10ujhh4/why_do_i_ge...
Input validation is important. PHP's mail() function has a parameter for "extra headers", which is often used to construct a From header on contact forms. This was exploited very frequently back in the early 2000s. I hope people have gotten more careful since then ...
The way it worked was that the "from" email address could contain CRLF and then a bunch of extra headers, even a message body, which would simply get injected.
The way it worked was that the "from" email address could contain CRLF and then a bunch of extra headers, even a message body, which would simply get injected.
> This was exploited very frequently back in the early 2000s.
And nobody has learned the lesson that “all user data is hostile” yet.
And nobody has learned the lesson that “all user data is hostile” yet.
The issue is also that most email clients will automatically convert URL's to links in HTML emails. So if an URL is put in e.g. your name field, it will still be clickable despite of no <a> tags.
We had a 'Contact venue form' in our last startup and were hit by spam. Filtering URLs and removing some .ru domains cut most of the spam.
I'm instead having people try to use my newsletter to "DDOS" other people (subscribe someone to 1000 newsletters, of which one is mine, and see how they like it). Subscription confirmation emails don't help, because now instead you get 1000 confirmation emails. Or at least that's what I think is happening.
> Or at least that's what I think is happening.
It is and isn't really a DDOS, it's a obscuration, see -
https://news.ycombinator.com/item?id=34865695
It is and isn't really a DDOS, it's a obscuration, see -
https://news.ycombinator.com/item?id=34865695
We only include the username, not the (optional) real name. If I had thought about it before now, I’d have said that sounds suboptimal. But now, I guess it was smart ;)
What's stopping the spammers from entering "http:// suspicious .link" as username and someone's real email as email?
Not OP, but usernames usually have restrictions to certain characters and lengths. It's pretty common to not allow : / and ., which would stop it. Space and @ usually aren't allowed either.
So "Go to superspammysite.com for horny pictures" is still an allowed username, right? Or of you skip spaces "superspammysite.com" may be enough that some spammer wants to abuse it.
I think you can't restrict usernames enough to not allow any spam. The only right way is to really just have the email and nothing else in the first confirmation mail.
I think you can't restrict usernames enough to not allow any spam. The only right way is to really just have the email and nothing else in the first confirmation mail.
Then you have "Hello superspammysite.com, welcome to our website." Not enough space for some kind of scam-text like in TFA. And considering that this has not happened in the last 27 years, it does not actually seem that worthwhile for spammers.
Good point. That still equips your competitors with all they need to ruin your reputation though:
email: [email protected]
username: F*YOU
submit!
Now your sending "Hey F*YOU!" to real people.
email: [email protected]
username: F*YOU
submit!
Now your sending "Hey F*YOU!" to real people.
Yeah, you can do that. But at that point you might as well sign up to a freemailer and just send those mails like that ;)
But then it's not coming from your company's email address.
Yeah, that does not seem like an important issue.
If the entire point of the operation is to tarnish the reputation of the company then it seems like an important thing to miss out.
Yeah, that, and length restrictions.
[deleted]
Good thing is, it looks like mail abusing isnt as easy anymore if hackers start abusing contact forms.
They do. It's funny to see what they write.
There are low tech and effective ways to tell bots from real people but I don't want to share them in public with possible bot writers here, sorry. If they know they don't care because they are successful enough without complicating their code a little bit more. If they don't know, don't tell them.
There are low tech and effective ways to tell bots from real people but I don't want to share them in public with possible bot writers here, sorry. If they know they don't care because they are successful enough without complicating their code a little bit more. If they don't know, don't tell them.
[deleted]
Was it Eric Jones spamming again?!
> This is one of those articles where reading the title is enough. No need to read the rest
then why isn't the title on HN what the article says is all we need to know?