CiviCRM Community Forums (archive)

Hi. We received a strange complaint that a visitor who was doing a donation, after receiving an error during the transaction, the donation form was showning credit card information other than his. It included the name, CC, expiration and CVV of another person who had made a donation just before him. At some point, we managed to reproduce the error, but not systematically.

The site was running CiviCRM 1.8 with PHP4. Since we finally had the host activate PHP5, the first thing we did was to upgrade to CiviCRM 1.9. After the upgrade, we were not able to reproduce the error, but we aren't very sure, since it's difficult to reproduce.

1- While investigating, we noticed that credit card information was stored in the Drupal sessions table. This, by itself, is a problem, since credit card numbers should be encrypted if stored. Altough, strangely, I think it is only for users who are logged in. But I don't think that makes sense, since any user, even anonymous, get a session cookie and an entry in the "sessions" table. Has anyone else noticed this? One way to check is to run the SQL query: select session from sessions where session like '%expiry%'; .. or to check for the word "Visa", 4540, etc.

2- We then found additionnal problems, but I don't know if it's from excessive testing and panic: after the upgrade to 1.9, we cleared the sessions table, cleared the cache, cleared my cookies, and now anonymous users cannot go past the first screen, it displays the following message: "Could not find valid Key". Here is the backtrace:

CRM_Core_Controller->key(CRM_Contribute_Controller_Contribution, , ) called at CRM/Core/Controller.php:136
#1  CRM_Core_Controller->__construct(, 1) called at CRM/Contribute/Controller/Contribution.php:57
#2  CRM_Contribute_Controller_Contribution->__construct() called at CRM/Contribute/Invoke.php:120
#3  CRM_Contribute_Invoke::main(Array ([0] => civicrm,[1] => contribute,[2] => transact)) called at CRM/Core/Component.php(183) : eval()'d code:1
#4  eval() called at CRM/Core/Component.php:183
#5  CRM_Core_Component::invoke(Array ([0] => civicrm,[1] => contribute,[2] => transact), main) called at CRM/Core/Invoke.php:144
#6  CRM_Core_Invoke::invoke(Array ([0] => civicrm,[1] => contribute,[2] => transact)) called at drupal/civicrm.module:319
#7  civicrm_invoke(contribute, transact) called at [(null):0
#8  call_user_func_array(civicrm_invoke, Array ([0] => contribute,[1] => transact)) called at includes/menu.inc:418
#9  menu_execute_active_handler() called at index.php:15

in the Core/Key.php "validate()" function, it returns null because: "if ( $k != md5( $sessionID . $name . $privateKey ) )".

We get that error from various browsers, computers, etc. To make things weirder, since it is a multi-lingual site, if we call the form with "[domain]/en/civicrm/contribute/[etc]", it *sometimes* does not make an error.

3- After an error (ex: a wrong credit card number, rejected by the payment gateway), then correcting the info, after the second attempt to validate, it still shows the non-corrected data and the transaction fails. The incorrect info shown again is not limited to the CC info, but also the name, address, etc. Even if I start again from the main start page of the donation, it still produces the bug.

Would upgrading to CiviCRM 2.0 help to solve these issues?
I'm also wondering whether this could have a link with the fact that the host is running Zend Optimizer.

Sorry for the long post. Thanks in advance for any advice.
Mathieu (bgm on #civicrm)

Matthew,
Good point, regarding storage of Primary Account Numbers...not just should be, but are required to be encrypted, by the VISA PCI Standards.
Hopefully, this has been addressed since the versions you are using, as there are penalties for non-compliance.
The VISA pages on the subject start at http://usa.visa.com/merchants/risk_management/cisp.html, and "CISP compliance is required of all entities that store, process, or transmit Visa cardholder data.", which includes all of us.
Specifically, the Payment Applications Best Practices http://usa.visa.com/download/merchants/cisp_payment_application_best_practices.doc?it=c|/merchants/risk_management/cisp.html|Payment%20Applications%20Best%20Practices%20
prohibit storage of the CVV.
This is a complex area, and these are the starting points...
I would encourage you to move to the latest versions, because Civi seems to be developing rapidly.
Ken

Hi,

I have turned off completely the Drupal cache and the credit card info is still stored in the Drupal sessions table. I have also tested on a site running CiviCRM 2.0.1 and the same problem appears.

The two sites use a different payment processor. 

Here is the contents of a problematic "sessions.session" entry:

language|s:2:"en";CiviCRM|a:6:{s:8:"domainID";i:1;s:12:"qfPrivateKey";s:64:"[key]";
s:11:"qfSessionID";s:32:"[hash]";s:71:"CRM_Contribute_Controller_Contribution_[key]";
a:16:{s:5:"qfKey";s:32:"[key]";s:2:"id";s:1:"1";s:6:"action";i:1;s:5:"bltID";i:5;
s:16:"paymentProcessor";a:13:{s:4:"name";s:13:"Authorize.Net";s:22:"payment_processor_type";
s:11:"AuthNet_AIM";s:9:"user_name";s:12:"[username]";s:8:"password";s:16:"[password]";
s:9:"signature";N;s:8:"url_site";s:49:"https://secure.authorize.net/gateway/transact.dll";
s:7:"url_api";N;s:9:"url_recur";s:49:"https://secure.authorize.net/gateway/transact.dll";
s:10:"url_button";s:0:"";s:7:"subject";N;s:10:"class_name";s:20:"Payment_AuthorizeNet";
s:8:"is_recur";s:1:"1";s:12:"billing_mode";s:1:"1";}s:6:"values";a:29:{s:2:"id";s:1:"1";
s:9:"domain_id";s:1:"1";s:5:"title";s:11:"[title]";s:10:"intro_text";s:322:"[intro text]";
s:20:"contribution_type_id";s:1:"1";s:20:"payment_processor_id";s:1:"7";s:19:"is_credit_card_only";
s:1:"0";s:11:"is_monetary";s:1:"1";s:8:"is_recur";s:1:"1";s:12:"is_pay_later";s:1:"0";
s:21:"is_allow_other_amount";s:1:"1";s:17:"default_amount_id";s:2:"45";s:10:"min_amount";
s:4:"1.00";s:14:"thankyou_title";s:9:"[thank you]";s:13:"thankyou_text";s:18:"Thank you message.";
s:16:"is_email_receipt";s:1:"1";s:17:"receipt_from_name";s:10:"[from name]";
s:18:"receipt_from_email";s:19:"admin@example.org";s:11:"bcc_receipt";s:18:"admin@example.org";
s:12:"receipt_text";s:16:"Receipt message.";s:9:"is_active";s:1:"1";s:22:"amount_block_is_active";
s:1:"1";s:21:"honor_block_is_active";s:1:"0";s:5:"value";a:4:{i:1;s:2:"50";i:2;s:3:"100";i:3;
s:3:"500";i:4;s:4:"1000";}s:5:"label";a:4:{i:1;s:0:"";i:2;s:0:"";i:3;s:0:"";i:4;s:0:"";}
s:9:"amount_id";a:4:{i:1;s:3:"150";i:2;s:3:"151";i:3;s:3:"152";i:4;s:3:"153";}s:13:"custom_pre_id";
s:1:"3";s:14:"custom_post_id";N;s:11:"footer_text";N;}s:6:"fields";a:0:{}s:22:"amount_block_is_active";
s:1:"1";s:15:"customGetValues";a:0:{}s:9:"groupTree";a:0:{}s:25:"separateMembershipPayment";
b:0;s:6:"amount";s:1:"1";s:9:"invoiceID";s:32:"[key]";s:14:"contributeMode";s:6:"direct";
s:6:"params";a:29:{s:5:"qfKey";s:32:"[key]";s:7:"email-5";s:16:"mathieu@example.org";
s:18:"billing_first_name";s:7:"Mathieu";s:19:"billing_middle_name";s:0:"";s:17:"billing_last_name";
s:5:"Lutfy";s:16:"street_address-5";s:14:"[address]";s:6:"city-5";s:9:"Montréal";
s:19:"state_province_id-5";s:5:"10000";s:13:"postal_code-5";s:7:"[postcode]";s:12:"country_id-5";
s:4:"1039";s:18:"credit_card_number";s:16:"[*** credit card number ***]";s:4:"cvv2";
s:3:"[**** cvv2 !  ****]";s:20:"credit_card_exp_date";a:2:{s:1:"M";s:1:"1";s:1:"Y";s:4:"2008";}
s:16:"credit_card_type";s:4:"Visa";s:6:"amount";s:1:"1";s:12:"amount_other";s:1:"1";
s:8:"is_recur";s:1:"0";s:18:"frequency_interval";s:1:"1";s:14:"frequency_unit";s:5:"month";
s:13:"selectProduct";s:9:"no_thanks";s:16:"state_province-5";s:1:"";s:9:"country-5";s:2:"CA";
s:4:"year";s:4:"2008";s:5:"month";s:1:"1";s:10:"ip_address";s:12:"67.XX.XX.XXX";
s:12:"amount_level";N;s:10:"currencyID";s:3:"USD";s:14:"payment_action";s:4:"Sale";
s:9:"invoiceID";s:32:"[key]";}s:4:"name";s:13:"Mathieu Lutfy";}s:18:"pastContributionID";
s:1:"1";s:11:"uploadNames";a:0:{}}_CRM_Contribute_Controller_Contribution_[key]_container|
a:5:{s:8:"defaults";a:0:{}s:9:"constants";a:0:{}s:6:"values";
a:3:{s:4:"Main";a:22:{s:5:"qfKey";s:32:"[key]";s:7:"email-5";s:16:"mathieu@example.org";
s:18:"billing_first_name";s:7:"Mathieu";s:19:"billing_middle_name";s:0:"";s:17:"billing_last_name";
s:5:"Lutfy";s:16:"street_address-5";s:14:"[address]";s:6:"city-5";s:9:"Montréal";
s:19:"state_province_id-5";s:5:"10000";s:13:"postal_code-5";s:7:"[postcode]";s:12:"country_id-5";
s:4:"1039";s:18:"credit_card_number";s:16:"[***** credit card number ****]";s:4:"cvv2";
s:3:"[*** CVV ***]";s:20:"credit_card_exp_date";a:2:{s:1:"M";s:1:"1";s:1:"Y";s:4:"2008";}
s:16:"credit_card_type";s:4:"Visa";s:6:"amount";s:18:"amount_other_radio";s:12:"amount_other";
s:1:"1";s:8:"is_recur";s:1:"0";s:18:"frequency_interval";s:1:"1";s:14:"frequency_unit";
s:5:"month";s:13:"selectProduct";s:9:"no_thanks";s:11:"_qf_default";s:9:"Main:next";s:
13:"_qf_Main_next";s:11:"Continue >>";}s:7:"Confirm";a:0:{}s:8:"ThankYou";a:0:{}}s:5:"valid";
a:3:{s:4:"Main";b:1;s:7:"Confirm";N;s:8:"ThankYou";N;}s:15:"_qf_button_name";s:19:"_qf_Confirm_display";}

How to reproduce:

- empty the Drupal sessions table: truncate table sessions; (this will reset the connection of all logged in users)
- go to contribution page
- enter details, cc info, etc. click submit to review
- select session from sessions;

My guess is that CiviCRM is storing quickforms data into the sessions table. Is there a way to avoid this?

Mathieu

Hi,

One interesting solution, I think, is how Ubercart proposes to encrypt CC data using a symmetric key stored in a file outside the web hierarchy.

In its configuration panels, it has a place where the admin simply needs to enter a directory, and Ubercart will generate a random key, store it in a file of that directory, and then will propose a procedure to encrypt existing stored CC numbers. (altough CiviCRM doesn't need that last step, since CC numbers are not stored)

However, that solution would not have avoided my bug, which was probably related to Drupal's cache, since the problem has not occurred since it was deactivated. i.e. the CC info was being legitimately displayed, only that there was a glitch in the user sessions. So I don't know if encrypting the keys stored in the sessions tables is really important, especially if we have a cron purging that data regularly.

I will implement the suggestions regarding the cron. About the CVV2, I might remove it from the form, since the CC gateway does not support them anyway.

Thanks,
matt