FYI, I have a 'feedback' form on my web site's home page which is now receiving what I consider to be a somewhat interesting attack vector that operates as follows:

1) A seemingly random IP address requests the home page using a seemingly random user agent string.
2) One or two seconds later, a POST is made using the home page feedback form from that same IP address.
3) between 30 and 60 seconds later, a different IP adress repeats the above.

I already block most spam of this type based on posted content, user agent string or known previous abuser IP address.

I did change the POST URL, and the 'attack' POST URL immediately changed after a home page reload - now that was interesting.

The current POSTs are not sending me emails, presumably due to the currently in place content blocking.

I do not find this bothersome as I'm not getting the emails. This is a heads up, and I found the POST URL change noteworthy. If this does become a pain in some way, I know that no human interacting with the web site would post feedback from the same IP address that had just loaded the home page and I would have another block method. At the moment I simply removed the feedback form from the home page, I might just leave this as an email address (which is already present) and be done with it.

James

Interesting. Thanks for posting.

I've had good luck with recaptcha to stop spam:
https://www.google.com/recaptcha

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

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.

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

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

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.

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.