Relatively sosistiphicated email form abuse

Interesting. Thanks for posting.

I've had good luck with recaptcha to stop spam:

https://www.google.com/recaptcha

@zunzun:

I did change the POST URL, and the 'attack' POST URL immediately changed after a home page reload - now that was interesting.
There are absolutely automated form submission bots out there that process the forms on the web page and submit them with random information. We used to get a lot of these on a franchise "interest" form on our site (most often advertising adult products or porn tube sites). In our case they actually filled in any text or textarea fields with their information and even used simulated email addresses (having @ and ending in a .com domain) on email fields so were probably looking at labels.

As you indicate the best defense is to implement form sanity checking (which is most likely dependent on your specific site and knowledge of submitters) upon receipt before taking action. I've also implemented limited network blocking (such as when I found a large percentage of such submissions coming from very few networks overseas where there was no way we'd have legitimate franchisee requests from).

Another thing, if you can assume Javascript will operate for legitimate users, is to use some dynamic Javascript to auto-generate some form information to assist in sanity checking on the back-end. It may not be 100% but in many cases I've found the agents are scraping the HTML but aren't operating a full browser engine so won't execute the Javascript.

– David

@deadwalrus:

I've had good luck with recaptcha to stop spam:

https://www.google.com/recaptcha

Not disputing your experience, but a wiki I help administer had a serious spam problem. reCAPTCHA helped for a while, but starting about 18-24 months ago the bots started getting through consistently, to the point where I considered it to be broken. I don't know the method, but given the difficulty of automated analysis, I suspect that humans were involved, either in a boiler-room type operation or a "solve this CAPTCHA to see this porn clip" set-up.

I responded by putting in a question-and-answer CAPTCHA, with a few questions relating to the subject matter of the wiki. Any real human who is interested enough to want to make an edit should easily know the answers, while robots or people who are randomly being presented with these questions out of context will not.

This stopped the spam edits to just a trickle, which could easily be dealt with manually. This may not be enough, though, as I've seen over the past two months a large number of the new wiki account confirmation e-mail messages bounce from Gmail with temporary or permanent failures. Apparently Google is able to identify Gmail accounts that are being used for spamming purposes (even non-e-mail spam) and throttles mail to them or shuts them down completely.

(I realize this is pretty much completely off-topic from the original post. Sorry about that.)

Another really simple way to detect human or not is to have a hidden form input. If that has a value on POST, you know it wasn't a human. We've used this with really good success instead of reCAPTCHA.

@tubaguy50035:

Another really simple way to detect human or not is to have a hidden form input. If that has a value on POST, you know it wasn't a human. We've used this with really good success instead of reCAPTCHA.
Interesting - I'm sort of surprised that this worked well, since I would have expected anyone bothering to write form parsing and completion code would leave hidden fields alone specifically for that reason - normal submissions would just be returning them as is. I don't think our fraudulent submissions were changing hidden fields, just the visible text fields.

– David

@tubaguy50035:

Another really simple way to detect human or not is to have a hidden form input. If that has a value on POST, you know it wasn't a human. We've used this with really good success instead of reCAPTCHA.

I've used this also, seems to work well.

@db3l:

Interesting - I'm sort of surprised that this worked well, since I would have expected anyone bothering to write form parsing and completion code would leave hidden fields alone specifically for that reason - normal submissions would just be returning them as is. I don't think our fraudulent submissions were changing hidden fields, just the visible text fields.

I was surprised as well. We also thought if bots were still getting through to hide a field with javascript and check that, but the hidden field is working so well that we haven't had to.

@Vance:

I responded by putting in a question-and-answer CAPTCHA, with a few questions relating to the subject matter of the wiki. Any real human who is interested enough to want to make an edit should easily know the answers, while robots or people who are randomly being presented with these questions out of context will not.

I do something similar for form registration. There's a profile option on registration that is a question. I even put the answer in the question. Dropped me from hundreds of false registrations a week to 1 or 2 (which I'd assume are spammers or crackers actually sitting down typing in the form)

One method for breaking reCatchpa is to use a service by purchasing "catchpa keys". you literally pay about .02c per entry and the auto-poster sends the recatchpa to somebody sitting in India or Pakistan or some other country where USD goes a looong way and that person types them in 8 hours per day.. serious. Since they are humans working along side the bots, I doubt there is anything you can do about it. This is how you can use software to auto-post on Craigslist and if the guys at Craigslist can't stop it, I doubt any of us can.