March 8, 2017

Online store payment fail

One of the most crucial parts of an online store is without a doubt the processing of payments. Can you believe that some of the largest online stores still screw this part up? ;-)

Two large online stores in Switzerland both shared the same heavy security flaw. They let client-side data interfere with the payment processing - without validating the outcome. I am not going to disclose the name of these online stores, because they have a reputation to loose and this is not why I am writing this article.

Rule #1 of web application security: never trust the client!

Payment service provider (PSP)

The role of a payment service provider is to accept a variety of different payments methods and handle those payments. The online store doesn’t want the risk of processing payments themselves and doesn’t want to bother with PCI DSS (Payment Card Industry Data Security Standards). This is why it makes sense to outsource this task to a payment service provider.

According to the documentation of the payment service provider, there are many ways how you can implement the payment page. (Redirect, lightbox, inline, hidden). The most simple integration is to post the required data to the PSP’s site and let them handle the payment. They then will redirect the customer back to the online store, when the payment was successful or failed. The PSP sends concurrently a separate confirmation request server-side to the online store itself.

Hidden client data

As a software engineer I like to know how data gets from A to B, especially when two different systems are involved. When you select your payment method in the online store and you then get redirected to the page of the payment service provider, some data is sent from A to B. The payment UI already pre-fills your name and the total amount of your cart, which means this data is sent at a minimum. When you view the HTML form in the source code of the online store, you can find some hidden fields that are submitted as well. These contain things like identifiers, external references etc. to make the payment work and to link the payment with the order.

The total amount of the cart is sent from the online store to the payment service provider. The PSP does not know if the cart has items in there for $100 or $25, because it has nothing to do with the checkout of the online store. Now, if you are thinking what I am thinking, yes, you can edit the amount in the form to $1 (or even $0.01) and on the PSP’s page the total amount is displayed accordingly. After the payment was successful the PSP calls the redirect URL of the online store to inform the customer if the payment was successful. The PSP sends parallel a separate confirmation request server-side to the online store with all the information about the transaction, including the amount that was payed. The online store then has to verify this data and then proceed with the shipping procedure.

Incomplete verification

🤦

The verification of the amount never took place!!

Both online stores don’t disclose how long this bug persisted and how many bad guys already abused this flaw, but this is heavy. I hope fellow engineers learn form this mistake and won’t build such an epic fail into their applications.

Lessons learned

Even when you think those large online stores must have code reviews, security audits etc. it isn’t always the case. To be fair, the online stores probably relied to much on the PSP, because they handle the payments, which gave them a false sense of security.

Tags: security, payment, e-commerce

« back

010100100110000101101110011001000110111101101101010000110110100101110000011010000110010101110010

About the author

human, software engineer, tech enthusiast, security researcher

E-Mail: blog@cipher.digital