Geek Answers Handbook

Stop server-side bot attack (without CAPTCHA or JavaScript)

I inherited some code that was recently attacked by repeated remote forms.

At first, I implemented some protection by setting a unique authentication session token (rather than a session identifier). Although I understand that this particular attack is not a CSRF, I adapted my solution from these posts (although dated).

I also read existing posts about SO, such as Image-based non-image-based CAPTCHA Practical Approaches?

However, the attacker now first requests the form page, starting an active session, and then passes the session cookie in the next POST request. Therefore, the presence of a valid session token. So not on my part.

I need to introduce some additional preventive measures. I would like to avoid CAPTCHA (at least for users) and JavaScript solutions, if possible. I also examined referrer checks (can be faked), honeypots (hidden fields), as well as speed limits (which can be overcome by throttling). This attacker is persistent.

With that said, that would be a more reliable solution.

+7
source share
4 answers

If you have a person who specifically attacks your page, you need to find what makes this attacker different from a regular user.

If he sends you spam with specific URLs or text or similar - block them after they are sent.

You can also submit quarantine materials - do not let them go for 5 minutes. During these 5 minutes, if you get another view in the same form from the same IP address, discard both messages and block the IP address.

CAPTCHA is good if you use a good CAPTCHA, because many custom homemade captchas are now automatically recognized by specially created software.

To summarize - your problem needs not only technical, but also social solutions aimed at neutralizing the botmaster, and not at preventing the publication of the bot.

+7
source

CAPTCHAs were invented precisely for this reason. Because there are NO ways to overcome 100% between a person and a bot.

You can throttle your users by increasing the counter on the server side, and when it reaches X times, you can consider it a bot attack and block the site. Then, when some time has elapsed (with the exception of the attack time), enable recording.

+1
source

I thought about it myself.

I had the idea to extend the auth session token to also store a set of randomized form variable names. therefore instead

<input name="title" ... >

You'll get

 <input name="aZ5KlMsle2" ... >

and then optionally add a bunch of trap fields that are hidden through css.

if any of the traps is full, then this was not an ordinary user, but a bot studying your html source ...

+1
source

How about a hidden form field? If it is automatically populated by the bot, you accept the request, but reject it.

0
source

More articles:


All Articles