Author Topic: Flooding control for CiviContribute (Read 3724 times)

xcf33 · March 28, 2011, 11:13:12 am

We have had occasions where people who stole credit card information tries to using the contribution form to test out if the stolen credit card was still valid. They build automated script to fill out and submit the contribution form. It results in us having to go to the payment processor and refund all the false contributions.

I'm wondering similar to a forum flooding control, can we check for if the same ip address has submitted certain contributions in a short amount of time and see if it is an automated attempt.

If this feature already exists, please ignore it.

Thanks,

Cheers!

Donald Lobo · March 28, 2011, 03:08:30 pm

For now might be easiest to do this with a drupal module. If i had to guess there might be a drupal module for this already that checks that a certain 'q' variable in drupal cannot be hit repeatedly by the same IP in a certain period

lobo

xcf33 · March 29, 2011, 06:51:50 am

I've searched a bit and so far not much luck. In addition, wouldn't the flood control be triggered on a POST on /civicrm/contribute/transact rather than just checking the q path?

I'm thinking about two ways of doing it.

1. create or insert time information from the PostProcess hook on contribution form that records session, ip address and time when it performed the HTTP POST

2. use some sort of session token

I'm leaning towards a non-database solution but not sure how to implement a session based mechanism.

Any direction would be appreciated!

Cheers

Donald Lobo · March 29, 2011, 07:22:18 am

hey chang:

the post variable also contains the 'q' param in $_REQUEST / $_GET, so u can use that. The main issue is, it does not contain the 'id' of the transaction page (and u may or may not want this restricted per page)

the session token seems good, but i suspect the smart hackers out there will clear out cookies before every transaction etc. Keeping it in the DB table is probably a better idea. I suspect u can reuse the cache tables for that (with a different path)

lobo

xcf33 · March 29, 2011, 07:33:40 am

The cache table seems like a terrific idea.

On the idea of restrict based on contribution page id, it is a good idea. It's possible to add the contribution page it in the build_form hook so it gets posted, correct?

I'm going to check submission interval in the civicrm_hook_validate hook and insert the cache record in the post process hook

Donald Lobo · March 29, 2011, 03:33:08 pm

yes, u can get the contribution page id in the postProcess

why dont u do it all in the buildQuickForm hook? if a submissions has happened already in the required interval then reject it at the very beginning of the process

lobo

Coleman Watts · September 12, 2011, 03:11:19 pm

Any working code for this yet? I need this too, but prefer not to reinvent the wheel if I can avoid it.

Eileen · September 12, 2011, 04:41:42 pm

Depending on your payment processor they might provide support for it. I know eWay had some anti-fraud features which we made available quite easily to Civi (basically you can configure it to reject transactions based on certain criteria )

Coleman Watts · September 12, 2011, 05:38:17 pm

Not auth.net, unfortunately, the best they can do is throttle number of transactions per day (globally, not per user). Which is a bad solution for obvious reasons.
I like dlobo's idea of using the cache table, and specifically throttling #post. It seemed elegant (lightweight and unobtrusive). I might just write a simple script for that if I don't hear back from changx.

Coleman Watts · September 12, 2011, 10:13:22 pm

Thanks changx for sharing your code.
It seems like this feature is important enough to warrant adding to core. Flood control is a sensible thing that most people should want -- it can prevent your organization from getting really screwed.

Here's my version -- much shorter than changx's because it uses the Drupal cache functions. It limits transactions to 2 per day from a single IP.

Code: [Select]

/**
 * Implmentation of hook_civicrm_postProcess
 */
function hook_woolman_civicrm_postProcess($formName, &$form) {
  // Record contribution submissions by IP address, store for 24 hours
  if ($formName == 'CRM_Contribute_Form_Contribution_Confirm') {
    $ip = ip_address();
    $n = 1;
    if (($c1 = cache_get('civicontribute_flood_1_' . $ip)) && time() < $c1->expire) {
      ++$n;
    }
    cache_set('civicontribute_flood_' . $n . '_' . $ip, 1, 'cache', strtotime('+1 day'));
  }
}


/**
 * Implmentation of hook_civicrm_validate
 */
function hook_civicrm_validate($formName, &$fields, &$files, &$form) {
  // Validate contribution pages for flood control
  // If 2 entries from this IP address exist, reject the form submission
  if ($formName == 'CRM_Contribute_Form_Contribution_Main') {
    $ip = ip_address();
    if ((($c1 = cache_get('civicontribute_flood_1_' . $ip)) && ($c2 = cache_get('civicontribute_flood_2_' . $ip)))
      && time() < $c1->expire && time() < $c2->expire) {
      watchdog('civicontribute_flood', 'Prevented contribution form submission from ip: ' . $ip);
      return array('qfKey' => 'Sorry, for security reasons we do not allow more than two credit card transactions per day. Please try again later.');
    }
  }
  return TRUE;
}

jcm55 · October 21, 2014, 07:59:13 am

Did anything like this actually make it into core? A bot was testing CC numbers against our contribute page and got our authorize.net account suspended for 30 minutes this morning.

joanne · October 21, 2014, 03:37:38 pm

I don't think it is in core and we actually wouldn't want it there.

We have over 1000 volunteers Australia wide and any one of them could want to submit more than two memberships at any time. (In reality, only a couple of people do so each month, but we could never predict which two people are the ones for any particular month.)

jcm55 · October 22, 2014, 08:13:16 am

Yes, agreed -- if added to core, it would need to have configuration options. Enable/disable, rate, and interval. So you could set the limit to 5 per hour, 10 per day, 50 per week, or whatever is appropriate for your org.

CiviCRM Community Forums (archive)

News:

Author Topic: Flooding control for CiviContribute (Read 3724 times)

xcf33

Flooding control for CiviContribute

Donald Lobo

Re: Flooding control for CiviContribute

xcf33

Re: Flooding control for CiviContribute

Donald Lobo

Re: Flooding control for CiviContribute

xcf33

Re: Flooding control for CiviContribute

Donald Lobo

Re: Flooding control for CiviContribute

Coleman Watts

Re: Flooding control for CiviContribute

Eileen

Re: Flooding control for CiviContribute

Coleman Watts

Re: Flooding control for CiviContribute

Coleman Watts

Re: Flooding control for CiviContribute

jcm55

Re: Flooding control for CiviContribute

joanne

Re: Flooding control for CiviContribute

jcm55

Re: Flooding control for CiviContribute