7

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

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.

Community
  • 1
  • 1
Jason McCreary
  • 71,546
  • 23
  • 135
  • 174
  • Have you checked how long the user has filled out the form? I would store a time in the session, then compare it once the form is filled out. If it is less than n seconds (maybe 2 or so) or more than y seconds (maybe 3600) then force it to refill the form again. –  Aug 09 '11 at 17:23
  • Is their a use case for a user to fill out the form more than once? – diedthreetimes Aug 09 '11 at 17:29
  • @Kevin, yes they are tightly submitted (~5 seconds). I though about adding this check. However, as noted in my question, the attacker could simply throttle their requests, say to every 35 seconds. – Jason McCreary Aug 09 '11 at 17:32
  • Have you also checked if they're using open proxies or possibly Tor exit nodes? –  Aug 09 '11 at 17:35
  • @Kevin, not familiar with that. Please elaborate. – Jason McCreary Aug 09 '11 at 18:18
  • If the attacker is using an open proxy or Tor, you should be able to block him by comparing his IP to a list. –  Aug 09 '11 at 19:55

4 Answers4

9

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.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • +1 for at least addressing the philosophy of the question. Any additional suggestions would be appreciated. – Jason McCreary Aug 09 '11 at 18:20
  • @Jason additional suggestions require understanding of details, i.e. what kind of attacks is performed, what is posted, are the attacks originating from one host or worldwide or ..., what the purpose of attacks is etc. I.e. the more details you can tell, the more meaningful answers you would get. Captcha can be not an option if posting involves human operators (eg. hired in India or China, where they get $1 per 1000 captchas recognized). – Eugene Mayevski 'Callback Aug 09 '11 at 19:00
  • The attack is relatively straightforward. The bot requests the form page (GET + starts session), they inject their values to the form and submit their request (POST + passing session cookie). Attacks seem to run every few seconds for about 10 minutes then they pause and start again from another IP. From what I can tell, they are testing credit card numbers. – Jason McCreary Aug 09 '11 at 21:20
  • @Jason the main question is what the purpose of their attack is. Is your form an ordering form for some goods or services? – Eugene Mayevski 'Callback Aug 10 '11 at 05:48
  • It's a donation form. *From what I can tell, they are testing credit card numbers.* – Jason McCreary Aug 10 '11 at 15:06
  • "they are testing ... " is a guess, if I get you right. If it's really so, then you need stop reporting success or failure immediately and report it, for example, by e-mail. The safest and most reliable, though, would be to switch to paypal or some other mechanisms (at least temporarily). – Eugene Mayevski 'Callback Aug 10 '11 at 18:06
  • 2
    This is a common kind of hack. Someone collects a large batch of credit cards via a virus and wants to know which have been cancelled and which still work. They find forms that let them test this cheaply, to avoid adding any additional red flags to the credit card accounts. The ones they confirm working they sell or run up charges on - the rest go in the trash. If you have a form that tells the user immediately whether their card is valid, you should expect this kind of attack. – Chris Moschini Oct 26 '11 at 07:38
1

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.

Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
  • I realize that. If CAPTCHA is the only option, so be it. But I'd like to believe there are alternatives focused on making it harder on the attacker, not my users. – Jason McCreary Aug 09 '11 at 17:31
  • My answer should be able to help you block at least most of the attack, the first 3-4 bots will pass, but at least not 20 or 100. – Madara's Ghost Aug 09 '11 at 17:35
1

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

David Chan
  • 7,347
  • 1
  • 28
  • 49
0

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

msc
  • 3,780
  • 1
  • 22
  • 27
  • This attacker is more sophisticated than that. I feel they would simply update their attack after analyzing the page. – Jason McCreary Aug 09 '11 at 17:22
  • 1
    So the bot-master will just tell them to ignore hidden fields... Remember that bots don't see the page the way you do, they scan the source code. If the bot-master enters the site and finds even a text input with `display: none;`, he can instruct the bots not to fill it. – Madara's Ghost Aug 09 '11 at 17:23