Thanks for the feedback, Justin... -----Original Message----- From: Justin Scott [mailto:leviat...@darktech.org] Sent: Tuesday, February 12, 2013 6:01 PM To: cf-talk Subject: Re: Problem with Hackers on Donation form through Authorize.net
> Forget the form page the bots/humans are not even seeing it they are > attacking your processing cfc directly. Your protection has to be server > side since any JavaScript on the form page is ignored. They are > submitting form data directly to your CFC processing page. Part of the verification in the processing can be reliant upon something executing in JavaScript and being passed in with the form submission. This is how CFFormProtect works (looks for and tracks timing, keystrokes, mouse movement, etc.). This data is tracked and passed in to the form and the server runs checks against it to determine whether the script ran and events occurred that you would expect to see in a "real" environment vs. an automated script (it does have some server-side checks as well such as Akismet lookups, etc.). It is true that an attacker could capture one "real" submission between the browser and the server and modify their scripts to submit the appropriate data to make it appear as though a script ran and those form fields were populated naturally when they actually weren't, though an attacker would need to be pretty persistent to go through all that trouble. The idea with these kinds of protections is to make it sufficiently inconvenient for an attacker to go to the trouble and move on to the next guy who is easier to exploit. One of the sites I ran years ago had a problem with people scripting the signup process to generate accounts (even to the point of generating e-mail accounts to use for the e-mail validation process). We really didn't want to use a CAPTCHA, so we ended up randomizing the form field names (and creating a map of the random names to the real names as a session variable when the form was generated so we could match them back up when it was submitted). This prevented the process script from being hit directly and would have forced them to load the actual signup page first, parse all the fieldnames out, and then run the submission again. They could have automated this as well, but never did (perhaps because it was too inconvenient and there were easier targets to go after). The earlier idea of automatically rejecting transactions and transparently showing a reject notice after a couple of failures is a good anti-abuse measure in this instance. If logs are being kept, they can be reviewed periodically and anyone who looks like they may have been accidentally rejected can be contacted again later to recapture their donation if needed. Abuse can be a hard problem to solve. -Justin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:354493 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
