As a security researcher, there's a unique hole in finding a vulnerability that is both simple in its nature and severe in its impact. This is the story of one such finding — a classic price manipulation flaw that could have had significant financial consequences.
Important Disclaimer: This vulnerability was discovered during a private bug bounty program. All identifying information about the company and its platform has been anonymized.
The Target: A Modern Payment Flow
The application in question had a standard, multi-step payment process:
- User selects a membership package (e.g., for €1500) and proceeds to checkout.
- The front-end confirms the order and its total price.
- The user is redirected to a third-party payment gateway/bank page to complete the transaction.
On the surface, everything looked secure. But the red devil was in the details.
The Hunt: Intercepting the Flow
My initial reconnaissance involved intercepting the HTTP requests between each step using a proxy tool like Burp Suite. The goal was to see what data was being passed around when the user moved from the cart to the external payment page.
I noticed that when the "Proceed to Payment" button was clicked, the front-end would send a final POST request to an internal API endpoint. This request contained a JSON payload with the order details (with new orderID), including a critical field: "amount": 1500.00.
Actually, the process seemed normal at first: you just create an order and wait for the payment link. But where is it? After order creation, an email arrives saying 'your order has been created and will be activated after payment.' But how do we make the payment? Is there another endpoint? Is it missing?
Anyway, it looks like someone hacked them before, and they made the system double-check :) It now requires both 'create' and 'approve' steps. But… what if someone finds the hidden approval endpoint and manually sets the status to 'approved'?
{
"order_id": "ORD_12345",
"amount": 0.50, // <- The malicious change
"currency": "EUR",
"description": "Premium Service"
}The result? The application's backend registered the order as fully paid, but for only €0.50 instead of the original €150.00. The entire payment process was compromised by a single, unvalidated parameter. Also with second scenario there is no real payment :)
The Impact: Beyond the Obvious
The implications were severe:
- Direct Financial Loss: Attackers could purchase high-value goods or services for a fraction of their cost.
- Reputational Damage: The company would lose trust if customers or partners discovered this flaw.
- Business Logic Failure: A complete breakdown in a core revenue-generating process
A Hard Bittersweet Conclusion
I documented the steps with clear evidence and submitted the report through the official bug bounty platform. The triage team confirmed the vulnerability and patched it within a few days.
While their swift action was commendable, the program ultimately decided this critical finding did not qualify for a monetary reward, which was disappointing. However, the intrinsic reward of making the web a safer place and the lessons learned are invaluable.
You might wonder why the company declined a bounty for such a critical finding. Their rationale was that their system still had a 'two-step protection' process in place. However, this defense is flawed because we had also successfully bypassed that second step. The unfortunate reality is that sometimes, bug bounty programs are run by companies whose developers lack a deep understanding of application security. This can lead to a failure to properly recognize and reward valid vulnerabilities, ultimately discouraging researchers from helping them improve their security in the future.
Sad but true i add the company also my black list.🖤
Stay with Panda!