Payments Gone Wrong !!

In the online payment process, merchants (seller) receive payments via the Internet or in situations when a payment is not physically presented to the merchant by the customer (buyer) at the time of the transaction. As an online merchant, you need to provide the highest level of payment security to assure your customers that their data are safe.

During the recent bug bounty engagement, I came across multiple payment integration bugs on different applications. Here, I will share few cases in which I was able to manipulate payments in one way or other. These are simple yet critical bugs that can cause serious financial damage to organizations.

The first application I was testing is a business analytics service company. It allows users to make payments either monthly or yearly.

In the request above, billingCycle parameter caught my attention as its value was 12 for yearly payments and 1 for monthly payments. From these two requests, it was clear that the application is using the value of this parameter to calculate the final bill amount.

Final Amount = (billingCycle * Base Amount) + taxes

I changed the value of billingCycle parameter to 0 and the final amount was $0.00 :D

This application allows users to buy credits that can be used later for services.

Payment Flow

In order to verify payment, the application checks if the request is legit or not. If the request is legit then it adds credits to the user’s account. So I sent that verification request to the repeater and each time I repeat the request, more credits will be added to my account again and again.

Payment Verification Request

This application is a food ordering app of a popular restaurant. While ordering food, we (me and Abhishek Jaiswal🕵️)decided to check if we can order for free. With that objective in mind, we decided to play with the payment flow of this application and soon enough we found a way to manipulate multiple components of payments such as discount, item price, etc.

When you add an item to your cart, the app will create a temporary cart for you. The endpoint “/api/v1/create_cart” that does this was protected against parameter tampering attacks.

create_cart request

But when you modify the cart i.e increase or decrease the number of items, the app will send a request to “/api/v1/modify_cart” endpoint with similar parameters and here you can actually modify any parameter. You can either change the price of items or add the discount amount of as much as you want. It will be substracted from the total bill amount.

Server-side validation compared with all inputs.Make sure sensitive signatures can not be re-used.Use something less obvious that is harder to tamper as a reference. Eg., a random string instead of an incrementing integer.