# How to prevent fraud attempts on Contribution pages?

An org I work with is reporting heavy fraudulent use (at least attempts to use -- it seems many are being declined in Auth.net, although some are getting through) of the CiviContribute form, despite the "I'm not a Robot" reCAPTCHA that is in place.

What are other ways to prevent these types of fraudlent attempts besides the Captcha on a profile? (I thought the Captcha would prevent it from even showing up in Authorize.net)

How hard this will be depends on how determined the service abuser is to adapt to the defenses you introduce, and how easy a target your site is compared to other sites available to the attacker. If you are seeing a significant level of abuse, this indicates that your site is one of the lower hanging fruit.

Here are a couple of options I've seen have good effect -

fail2ban - We've used fail2ban effectively for assorted spam and abuse prevention. An approach to this looks like:

• In this hook, error_log to some logfile.
• Add a fail2ban jail with this logfile which uses iptables to ban addresses that look suspicious.

There is a risk of banning legitimate IPs here, eg a single IP which many supporters sit behind (maybe you are a union and half your members are behind a certain corporation's firewall) or your own head office if they make a large number of transactions. So this is an approach to use with some considerations.

This approach is more effective if you are seeing repeat abuse from the same IP addresses; you can identify this by inspecting your webserver logs for the contributions (grep for POST requests hitting civicrm/contribute/transact then group by IP and count requests).

custom spam checks - I've seen form abuse drop off entirely simply by adding an additional required question. You can add this to your form, then use JS in your page to hide the field and populate it. This can be more effective than reCaptcha because reCaptcha is common enough to be worth automating for a botnet, but if your form is one of several they are outsourcing their CC checks to, then you only need to make your form less easy to abuse than others.

This approach is effective against abuse where the attacking engine is less sophisticated than a web browser (ie lacks the JS engine in the browser). It's easy to test out.

• Thanks, Chris! I am considering implementing the second option here as the attempts are ongoing... – Laryn - CEDC.org May 19 '15 at 14:55
• @Chris brilliant! Do you have source code you can share for this? – Jon G - Megaphone Tech Mar 30 '16 at 0:36
• @JonG we just struggled with this same issue. Per your request, about year late ;), here is a bit I wrote/installed to deter the current set of fraudsters: github.com/elisseck/com.elisseck.civihoneypot. Only works for contribution pages right now but should be pretty easily adaptable to other forms as well. – Eli Lisseck Apr 19 '17 at 20:15

You can use the flood control extension posted on the CiviCRM blog here.

There's an even smaller extension that does the same thing, but is Drupal-specific here.

• Also looking at implementing @Coleman's Drupal-based flood control script -- do you know what gets presented to an end-user who may get caught up in the new submission limits? Is there an error message of some kind? – Laryn - CEDC.org May 19 '15 at 14:54
• In that example the error message is generated in hook_civicrm_validate: "Sorry, for security reasons we do not allow more than two credit card transactions per day. Please try again later." – John Jul 8 '15 at 13:39

If you are using drupal you can use https://www.drupal.org/project/httpbl. One of it settings are: use on all pages (so, including civicrm contribution pages). It is being used on huge sites, among others drupal.org itself.

• Trying this out now. In your experience does it solve things pretty quickly or take some time to phase the problems out? – Laryn - CEDC.org May 19 '15 at 14:49
• it should work very quickly – Catorghans May 20 '15 at 15:33
• httpbl doesn't help much with stopping/reducing fraud. It's more for spammers who will follow the links. Fraud is trying to complete the form. On our client that's getting fraud, they already have httpbl on all pages and it's not helping. – herb Aug 11 '16 at 14:05