Stopping a bot attack server side solution (without a CAPTCHA or JavaScript)

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

Initially I implemented some protection by setting a unique session auth token (not the session id). While I realize this specific attack is not CSRF, I adapted my solution from these posts (albeit dated).

• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
• http://tyleregeto.com/a-guide-to-nonce
• http://shiflett.org/articles/cross-site-request-forgeries

I've also read existing posts on SO, such as Practical non-image based CAPTCHA approaches?

However, the attacker now requests the form page first, starting a valid session, and then passes the session cookie in the following POST request. Therefore ha开发者_如何学Pythonving a valid session token. So fail on my part.

I need to put some additional preventative measures in place. I'd like to avoid CAPTCHA (do to poor user experience) and JavaScript solutions if possible. I've also considered referrer checks (can be faked), honeypots (hidden fields), as well as rate limiting (which can be overcome by throttling). This attacker is persistent.

With that said, what would be a more robust solution.

If you are having a human that attacks specifically your page, then you need to find what makes this attacker different from the regular user.

If he spams you with certain URLs or text or alike - block them after they are submitted.

You can also quarantine submissions - don't let them go for say 5 minutes. Within those 5 minutes if you receive another submission to the same form from the same IP - discard both posts and block the IP.

CAPTCHA is good if you use good CAPTCHA, cause many custom home-made captchas are now recognized automatically by specially crafted software.

To summarize - your problem needs not just technical, but more social solutions, aiming at neutralizing the botmaster rather than preventing the bot from posting.

CAPTCHAs were invented for this exact reason. Because there is NO WAY to differentiate 100% between human and bot.

You can throttle your users by increasing a server-side counter, and when it reaches X times, then you can consider it as a bot attack, and lock the site out. Then, when some time elapse (save the time of the attack as well), allow entry.

i've thought a little about this myself.

i had an idea to extend the session auth token to also store a set of randomized form variable names. so instead of

<input name="title" ... >

you'd get

<input name="aZ5KlMsle2" ... >

and then additionally add a bunch of traps fields, which are hidden via css.

if any of the traps are filled out, then it was not a normal user, but a bot examining your html source...

How about a hidden form field? If it gets filled automatically by the bot, you accept the request, but dismiss it.