The hacking has slowed down some; there's only been three or four attempts in the last couple of days. Nothing I've done, since it's apparently a human hacker, and the only thing I'm using now is a CF-generated captcha set to medium. So, that's not stopping the hacker. Perhaps the hacker has just moved on to another target for awhile.
When (not if...) it starts up again, I'm going to try the javascript timing function, timing when a form element is first clicked and making sure it takes at least 2 minutes until the form is submitted, or I'll fail the transaction. None of the hacker's attempts have taken more than about 1 min 15 sec, and most are about 15-30 seconds, so, hopefully, that will be just enough of an irritant to run the hacker off. If the hacker is bypassing my form, however, which depends on javascript to function, and is attacking my CFC which submits the form when all CF validation is passed via CFHTTP, I wonder if the hacker can still submit the form with javascript turned off? How would I go about determining just what the hacker's process is? And if the hacker is disabled javascript, I guess I can use a session variable in CF to check the time for the start and end of form input. But if, he's (or she's) attacking the CFC method directly, would the form timing even be relevant? I wish I could send enough of an electric shock through hackers' keyboards to knock them out for an hour...maybe someday. I can only hope! -----Original Message----- From: UXB [mailto:denn...@uxbinternet.com] Sent: Wednesday, February 13, 2013 9:23 PM To: cf-talk Subject: RE: Problem with Hackers on Donation form through Authorize.net >> Part of the verification in the processing can be reliant upon something >> executing in JavaScript and being passed in with the form submission. While I do not disagree with your statements anything that is part of the form data that can be generated by JavaScript can be submitted without it by, as you said, capturing a "real" form submission and then simulating it. The final protection has to be server side because you cannot rely on the data sent by the client. >> 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. >> Abuse can be a hard problem to solve. Very! It is almost always proportional to the potential gain of the abuse. In Rick's case there is a fairly high financial gain to be had by the verification of credit card numbers. Like you we had a donation page for a client and they too were getting a large number of abusive submissions until we but it behind a signup/login page that required a valid email address and a easy to read captcha. In that case it solved the issue and they had no more problems but then they were clearing the CC numbers manually so there was always human oversight. Dennis Powers UXB Internet - A website Design and Hosting Company P.O. Box 6028, Wolcott, CT 06716 - T:203-879-2844 W: http://www.uxbinternet.com W: http://www.ctbusinesslist.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:354498 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
