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 having 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.