Do spambots directly POST to the server or fill out HTML forms?

Question

I am looking for an alternative to Captcha (or Recaptcha) for the registration form on the website I'm working on.

I believe Captcha negatively affects UX. I studied the use of hidden fields, but apparently they are not effective (link: http://radio.javaranch.com/davo/2008/10/15/1224063498569.html )

A comment on this article says:

As someone who writes CAPTCHA crackers as part of my work (no, not for spam), I can assure you that a hidden field will in no way travel me. As another poster was mentioned, I check on wired traffic and don’t pay much attention to what happens in the HTML form.

This led me to believe that spambots made direct POST requests to the server, rather than requesting a form and filling out it.

If so, what should I do if I create a hidden, read-only field that I pre-populate with a hash stored in SESSION. When a user submits a form, I can compare the values. Will this work as a way to avoid spam bots, or am I watching something?

If the form is never requested, I, of course, will not find the hash stored in the session, and therefore can ignore the request.

Answer 1

Adding another field with a call associated with a server-side session variable is a good approach; this will require significant efforts from spam bots, i.e. they must download and parse the form, fill it out and make another request (sending the necessary cookies).

You can also consider adding JavaScript to modify a given task and modify it in a specific way. Then the attacker needs to figure out what your code is doing before they can automate its replication. Transforms can be simple rot13 or more complex xor operations. Things like md5 , sha1 are established algorithms, so they are a poor choice; it should be ordinary.

Of course, if an attacker is tied to targeting your site, you cannot do this to prevent spam from entering; what an ugly truth. For example, they can run Selenium and bypass all your JavaScript protection.

Answer 2

Unfortunately, I suspect that you already have spammers specifically designed for your site. If you manually implemented login and registration, it is unlikely that the spambot would have logic that can register without being specifically adapted to your forms.

Other solutions are good, and although they will help, none of them will prevent even a moderately defined spammer. A lot of spam bots function as browser plugins, therefore, believing that a spambot can not evaluate JavaScript or will not require a form in the first place, it is unlikely to help you for a very long time. At the very least, a CAPTCHA to register (and possibly for every message or what your site does, until an account is manually approved) is likely to be required.

I know that you do not want to influence the user interface, but spam messages and accounts are much more harmful to UX than CAPTCHA. Bite the bullet and do your best to slow down the spammers, or your users will look elsewhere.

Of course, CAPTCHAs are not complete solutions - there is software that can solve them (in some cases) more accurately than people. They, like enriched breakfast cereals, are just part of this full breakfast - and no one in their right mind will start a day off with SPAM .;)

Upgrading new users is likely to be very useful.

Answer 3

I would say it depends on the bot. If someone is targeting your site, this can be easily circumvented:

• Request a page with a form and fill in the session value
• Fill out the form and submit.

I would say that this is almost no defense.

Unfortunately, I am not very familiar with the current state of bots and how they work, so this is just my contribution to how easy it would be to get around this implementation.

Answer 4

Different spambots use different methods.

But the most flexible spam bots: 1. request a page with a form 2. read which fields it contains 3. Send a POST request with the fields found with some filled values

You can’t be sure that all bots can find and leave their input "form-session-token". You cannot be sure that all bots can use javascript (another way of protection is to add the required onsubmit field with js). But the bots are many and different.