security issue troubleshooting

[helenbn]

Hi,

I have a client that uses CiviCRM 4.5.7 and Joomla 2.5.x with Authorize.net payment gateway, SSL that is not Heartbleed vulnerable and no Captcha activated for CiviContribute. (I know there is Civi 4.5.8 and J 3.x) Sucuri scan reveals no malware.

Within Authorize.net transaction records, 250+ show declined transactions on one day for the same amount, different credit cards, trash names and emails while no transactions are recorded within CiviCRM. Is it possible for someone to do this with Civi? (Since my client has activated reCaptcha.)

Thanks,
Helen

[Hershel]

Is it possible for someone to do this with Civi?

I don't see why not. That is why there are CAPTCHA tools available.

[helenbn]

Hi Hershel,

Captcha prevents robots. I understand this.

My question relates to bypassing Civi:

Within Authorize.net transaction records, 250+ show declined transactions on one day for the same amount, different credit cards, trash names and emails while no transactions are recorded within CiviCRM.

If transactions can bypass Civi, this would appear to be a serious security issue.

[Hershel]

I'm not following you. Authorize.net says the transactions were denied. That means they were never completed and so therefore CiviCRM never recorded them. That's how it works.

Why do you think CiviCRM was "bypassed?"

[helenbn]

I thought every transaction gets entered in Civi, then the payment attempts to process and the status gets updated: completed, failed, etc. So the failed = denied. 

[helenbn]

I have programmed a few ecommerce sites and the flow chart would be

order placed and status pending in Joomla>gateway connection and processing>processing completed or denied>status updated in Joomla

Is it not the same way in Civi?

[Hershel]

You can confirm this for yourself by making a bad payment and see what happens. Go to your own site not logged in, enter some random data so that your payment will be declined. Then check if any record of your attempt was stored in CiviCRM. Don't make a user of course--just try to pay.

[helenbn]

If you could just tell me if CiviCRM is performing as intended, that would be so informative. I don't see anything in the tutorials that goes over this. Of course, I could have missed it. I am not doubting you. I just don't have any written word of how this scenario is suppose to work.

[joanne]

I'm not following you. Authorize.net says the transactions were denied. That means they were never completed and so therefore CiviCRM never recorded them. That's how it works.

As I read it, this quote does tell you that CiviCRM is performing as intended. (The bolding is mine)

I am not doubting you. I just don't have any written word of how this scenario is suppose to work.

And, sorry to be so blunt, but you are doubting him and the written word he provided.


Hershel's suggestion that you try it out for yourself seems the most sensible suggestion under the circumstances.

[helenbn]

Alas, my attempt to make sure I was not misunderstood has been misunderstood.

Thank you both for your time.

[petednz]

At risk of opening a closed ticket, my expectation is that if someone makes an unsuccessful payment through civi then civi does record it as an incomplete/failed transaction.
my reading of what you say is that there were 250 incomplete transactions in authorise but no equivalent record in civi.
to submit 250 via civi would in my view result in 250 transaction records being recorded in civi.
so unless i totally mis-read this thread, it does sound like you have a cause for concern but i can't suggest where that concern might need to be directed.

i have heard stories about stolen cc numbers being 'tested' via websites including civi, but my understanding was that such testing did result in civi transaction records being created.

[petednz]

late thought - can you get the client to absolutely confirm that civi is the ONLY interface that is wired to their payment gateway or do they have some old forgotten site that could be the route being used?

[joanne]

Each payment processor may be different , but I can confirm that for Eway a failed online payment does not create a contribution record in civicrm.

I do have a contact record for that person in CiviCRM, but as our system is set up to require account creation and custom fields for all online transactions I can't say whether or not that will be the case for every installation.

@helenbn, as I see it, the best approach is for you, or your client, to enter a transaction that is guaranteed to fail using the online form that requires the least information and see what happens.  You will need to enter a valid credit card number, but an incorrect expiry date or CSC should ensure the transaction will fail.

[helenbn]

Thank you petednz for your concern.

Upon contacting Authorize about this issue, they explained that "...people trying to process fraudulent transactions will use donation pages like ours to try to figure out algorithms or valid card numbers."

Civi is the only extension using this Authorize account. Authorize is very picky about sharing accounts. My client has multiple accounts just for this reason.

Upon testing my client's site with my own credit card info and incorrect security code and expiration date, the following message posted on the top of the donation page:

Payment Processor Error message
2: 65 This transaction has been declined.

However, no record was created within CiviCRM.

Upon reading other forum posts, it appears that this same problem has been touched upon but with no follow up that I can see:
http://forum.civicrm.org/index.php/topic,23359.0.html. This appears to be dependent solely upon Civi and not the payment gateway. The "failed" status is available within the backend but never gets used?

So I +1 to recording failed transactions in the Civi database.

Hopefully this post correctly explains what happened and why and will helped others in this forum.