With Drupal+Ubercart, be wary of alternative payment gateways
If you are using Ubercart to do ecommerce with Drupal, be sure to use one of the mainstream payment gatways: Authorize.net or Paypal.
While Ubercart does support a number of alternative payment gateways, the dangers in going with these alternatives are significant. Here's an example of a single day where two of the less well known Ubercart payment modules were exposed as having flaws that allow people to checkout without needing to pay:
SA-CONTRIB-2010-062 - Ogone | Ubercart payment - Access Bypass
SA-CONTRIB-2010-064 - Ubercart MIGS Payment Gateway - Web Parameter Tampering
This means the cornerstone of your ecommerce - payment - could be completely side-stepped. This is is just one example of why we recommend using one of the mainstream gateways.
I do not mean to disparage the hard work of those individuals – I know both the maintainers and coordinators within the Drupal security team worked hard to get timely fixes published. However if you (or your client) must select an alternative gateway, it's vital that you commit adequate time to testing and Q/A of the payment processor.
Comments
On what basis do you assert that the default payment processors in Ubercart _are_ secure and according to gateway specification?
In other words, wouldn't you commit equal adequate time to testing and Q/A of the default payment processors?
Fri, 06/18/2010 - 11:20
You're actually saying two different things here. In the first paragraph, you say that you should be SURE not to use any gateways other than Authorize.net or PayPal, but then in the rest of the article, you point out that one should be doing sufficient testing on alternate gateways.
I appreciate the heads-up on security issues with two specific payment gateway implementations, but one should not conclude from these two examples that every single other payment gateway module is automatically flawed and should not be used. I feel like you're crying wolf a little here. If there are issues with other gateway modules, please do highlight them, but I do feel that this post creates FUD.
Fri, 06/18/2010 - 23:51
I agree there's absolutely no guarantee of safety when using a big-name gateway either. I don't mean to imply that you can blindly trust popular modules; but in my experience they require vastly less time to test.
The reality for developers is that the Q/A budget is finite. A recent Ubercart project I completed contains over 300,000 lines of code (including core, Ubercart, and other contributed modules). This is a pretty typical setup, and it's simply not possible to exhaustively test every line of code.
As a result, testing tends to be supplemented with other proxy measurements, including:
- Past experience with the module
- The activity in the project's commit logs and issue queue on d.o
- Coder module checks
- Usage stats
While not perfect, the usage stats do reveal a lot about the amount of testing likely to have been performed by other users. This peer review is one of the reasons we choose open source in the first place!
Getting back to payment gateways, the median usage for alternative gateways is 12, compared to over 18,000 for Ubercart itself.
| Module | Usage |
| uc_alipay | 48 |
| uc_ccavenue | 4 |
| uc_dineromail | 14 |
| uc_dotpay_pl | 10 |
| uc_ebs | 5 |
| uc_echopay | 3 |
| uc_epdq | 9 |
| uc_eway | 74 |
| uc_flo2cash | 2 |
| uc_gestpay | 12 |
| uc_migs | 15 |
| uc_moneris | 53 |
| uc_mpay24 | 1 |
| uc_mygate | 6 |
| uc_nbepay | 3 |
| uc_netbanx | 4 |
| uc_ogone | 63 |
| uc_paymentexpress | 20 |
| uc_protx_vsp_direct | 113 |
| uc_realex | 15 |
| uc_saferpay | 8 |
| uc_securepayau | 15 |
| uc_securetrading | 18 |
| uc_skipjack | 10 |
| uc_tranzila | 13 |
| uc_turkish_banks | 5 |
| uc_webmoney | 54 |
| uc_zpayment | 20 |
Thu, 08/26/2010 - 16:51
I was just looking at this long list of payment processing companies and was wondering which one to go with... Problem solved! Paypal it is!
Sat, 01/08/2011 - 21:59
One way to solve this problem, at least in part would be to have a PHP payment processing library hosted on github and shared across multiple projects. It is not very efficient for each gateway/processor to be reimplemented for each project. The RoR community has this with ActiveMerchant and it would be nice to see it replicated for the other popular languages, firstly PHP and Python.
Fri, 06/18/2010 - 08:50