RE: Problem with Hackers on Donation form through Authorize.net
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
RE: Problem with Hackers on Donation form through Authorize.net
Thanks, Dennis! -Original Message- From: UXB [mailto:denn...@uxbinternet.com] Sent: Tuesday, February 12, 2013 5:31 PM To: cf-talk Subject: RE: Problem with Hackers on Donation form through Authorize.net button for my form is just a regular button that triggers an AJAX function that sends the data to a CFC for further processing and then submission 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. 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:354494 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Issues after applying Coldfusion patches
All - Our admins have been applying patches to our Coldfusion servers (version 8). They said most of the patches affect coldfusion admin. During testing coldfusion administrator after applying patches, I found that verifying databases would throw this error There was an error accessing this page. Check logs for more details..The log file just has this error *There was an error while verifying the token. Either the session timed out or un-authenticated access is suspected.* * * Any suggestions on this? Thanks ~| 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:354495 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Issues after applying Coldfusion patches
Double check that you are installing the hotfix for the correct version of CF, eg that they are not installing a CF9 patch on CF8. -- Pete Freitag - Adobe Community Professional http://foundeo.com/ - ColdFusion Consulting Products http://hackmycf.com - Is your ColdFusion Server Secure? http://www.youtube.com/watch?v=ubESB87vl5U - FuseGuard your CFML in 10 minutes On Wed, Feb 13, 2013 at 2:36 PM, funand learning funandlrnn...@gmail.comwrote: All - Our admins have been applying patches to our Coldfusion servers (version 8). They said most of the patches affect coldfusion admin. During testing coldfusion administrator after applying patches, I found that verifying databases would throw this error There was an error accessing this page. Check logs for more details..The log file just has this error *There was an error while verifying the token. Either the session timed out or un-authenticated access is suspected.* * * Any suggestions on this? Thanks ~| 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:354496 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
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:354497 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Problem with Hackers on Donation form through Authorize.net
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
