Learn how Cobalt’s Pentest as a Service (PtaaS) model makes you faster, better, and more efficient.

Parameter Tampering Vulnerability Using 3 Different Approaches

Core Pentester Seli Feta has created a blog to help readers understand how online payments work and offer steps for learning how to execute Parameter Tampering attacks

With the growing number of online transactions increasing, it is clear that payment security is crucial. I have created this blog to help readers understand how online payments work and offer steps for learning how to execute Parameter Tampering attacks.

How E-payments Work?

1. The customer decided which product to purchase from the company.

2. When clicking on the bottom payment the customer is redirected to the order page, enters their payment information {card information, identification, etc}, and then submits the payment request.

3. The online payment provider system sends the customer’s payment request to their bank account for the bank purchase approval.

4. If the customer’s card details are valid and there are sufficient funds to complete the transaction, the customer’s bank will confirm the purchase. However, if the transaction is declined for any reason - invalid credentials or insufficient funds - then funds will not be transferred but status information will still be sent to your website.

5. The issuing bank will pass on its approval or refusal to the acquiring bank.

Now that we have a general understanding of how an electronic payment works, let’s explore Parameter Tampering Vulnerability and look at how it can be implemented using three different approaches.


Parameter Tampering

Essentially, Parameter Tampering is a web-based, business logic attack. It involves the manipulation of the parameters exchanged between client and server to modify the application data such as user credentials, permissions, price, the number of products, etc. It is intended as a business security threat that involves an unauthorized party manipulating and tampering with the website’s URL, web page form, or other parameters.

Now let’s dive into the three scenarios: changing a cheap product to an expensive product, unlimited cards, and changing price.

1. Changing a Cheap Product to an Expensive One Scenario

While making a payment, a product is added to a basket on an application. A request is made for the cheaper product and the parameters of the request are saved before the product goes to the bank for approval. Subsequently, a request is made for the expensive product but is replaced with the information about the cheaper product and again sent to the bank for approval. The bank then approves the cheaper product.

Let’s take a look at an example:

Original Request:


Edited Request:


The parameters of the approved cheap product by the bank can be kept constant, and the "oid", "transid", and "orderid" parameters are changed in the request allowing the expensive product to be bought for the price of the cheap product.

Response from the bank:


Balance received from the bank:


As seen in the screenshot, the order has been successfully completed.

Order summary:


2. Unlimited Card Scenario

A product that is added to the basket cannot be confirmed by the bank because the balance is insufficient. The "errmsg" parameter in the request, displayed in the screenshot, shows the value of "CARD + SALE + LIMIT + INSUFFICIENT" since there is not enough in the user’s credit card balance.

Original Request:


However, when the "errmsg", "response", and "procreturncode" parameter values in the request are updated, it approves the order.

Edited request:


As seen in the screenshot, the order has been completed successfully.

Order completed:


The product could then be added to the basket and bought without paying any money.

Order summary:


3. Changing Price Scenario

In this scenario, the price value can be easily changed by lowering the price and passing the order for payments.

While making a payment, a product is added to the basket on the application. In the customer payment request, the price is then edited in the request and sent for bank approval. As seen in the screenshot, the request is intercepted before it is sent to the bank and the "Total Amount" and "Amount" parameters are changed to a different price. The transaction value of the product is changed from "409.98 " to "0.98" and sent to the bank.

Original Request:


Edited request:


SMS received from the bank:


As seen in the screenshot below, the order was successfully completed with the final price being 0.98TL:


I hope you found the scenarios interesting. Happy Hunting!

Additional Resources: Web Parameter Tampering How exactly does online payment work What is parameter tampering

Back to Blog
About Selvie Feta
Selvie is a Core Pentester and has been an application security consultant with 4+ years of experience. She holds OSCE, OSCP, OSWP, eWPTX and eMAPT certifications. She has experience in Web application, APIs, Mobile application, and Network pentest. Also, she performs source code review and payment security. More By Selvie Feta
Introduction to Serverless Vulnerabilities
Core Pentester Harsh Bothra introduces us to serverless vulnerabilities. He reviews the top 10 vulnerabilities and concludes with how to remediate them.
Nov 23, 2022
Pentester Spotlight: Harsh Bothra
From blogs to mind maps, Harsh Bothra shares how he creates engaging security content for his community!
Jan 27, 2022