From Good Disclosure to Silence, A Business Logic Price Manipulation Story

Introduction

In 2022, as a regular customer of an e-commerce platform, I came across a couple of stored XSS issues and a minor business logic flaw while browsing the site. I reported them directly to the company. The response was fast, the fixes landed quickly, and they even thanked me with an invite for coffee, I couldn't make it since we were in different cities, but the whole process was a good example of how vendor communication should work.

In 2023, on the same platform, I found something considerably more serious.

All testing described here was performed as a regular, unauthenticated customer interacting with the publicly available checkout flow, no credentials or internal access were used beyond a normal shopping session. The vulnerability has since been fixed. Company name, domain, and any identifying details have been redacted throughout; the domain is referred to as xyz.com and field names have been generalized.

Finding: Client-Side Price Enforcement in the Checkout Flow

While going through the checkout process as a guest, I noticed that after entering shipping and billing information, the request that submitted the order also carried the order's total amount as a plain, client-editable form field.

A simplified, redacted version of the intercepted request looked like this:

POST /payment-guest HTTP/2
Host: xyz.com
Cookie: ci_session=<redacted>
Content-Type: application/x-www-form-urlencoded

firstName=a&lastName=a
...
&consentAccepted=1&toplam_tutar=280

The toplam_tutar field was accepted as-is, with no server-side recalculation based on the actual cart contents or listed product price. Changing it in transit, for example, it was enough to reduce the total amount from total_amount=280 to total_amount=1 and send the request.

The platform used iyzico as its payment service provider. Right after the tampered request above, the checkout flow made a follow-up call to iyzico's own API to generate the installment/checkout form, and the tampered value carried straight through:

POST /payment/iyzipos/checkoutform/installment HTTP/1.1
Host: api.iyzipay.com
Referer: https://xyz.com/
Content-Type: application/json
X-Iyzi-Token: <redacted>

{
  "price": 1
}

From there, the flow proceeded exactly like a normal payment: entering card details triggered the standard 3-D Secure verification, and a one-time SMS confirmation code was sent to the phone number tied to the card, for a transaction of 1 TRY instead of the actual 280 TRY order value. The payment was not completed beyond this point, but the OTP request itself confirms the tampered amount had already reached the real payment gateway as a genuine, processable transaction, not just a client-side display value.

This is a textbook example of client-side enforcement of a security-relevant value (CWE-602): the server trusted a number the client was free to change, instead of treating the client as untrusted input and recalculating the authoritative price itself.

Impact

• Any customer could push a purchase through to the payment gateway at an arbitrary, self-chosen amount, in this case the payment provider's 3-D Secure OTP flow was triggered for 1 TRY instead of the real 280 TRY order value, confirming the tampered amount was accepted as genuine by the payment provider itself, not merely reflected on the client
• Had the flow been completed, this would have resulted in direct financial loss on every order placed this way
• Downstream inconsistencies in accounting, inventory, and order reporting, since the recorded "paid" amount would never match the actual product price
• No special access or authentication bypass was required, any regular customer session was enough

Disclosure Timeline

The contrast with the 2022 experience is what makes this worth writing about. While the vulnerability was open, communication was quick and cooperative. The moment it was patched, and once a reward was asked for, communication stopped entirely, no "thank you," no decision on the request, no closing message, nothing.

This isn't a one-off. It's a pattern some organizations fall into: engagement with a researcher lasts exactly as long as the researcher is perceived to hold leverage. Once the risk is gone, so is the courtesy.

Remediation

• Never trust client-supplied pricing. The order total must be computed server-side, from the actual cart contents, current catalog prices, and any legitimate discount logic, on every checkout request.
• Re-validate at the payment gateway boundary. The amount sent to the payment provider should be derived independently, not passed through from an earlier client-controlled request.
• Add integrity checks between steps. If the checkout flow is multi-step, sign or otherwise bind the cart state between steps so it can't be silently altered in transit.
• Log and alert on mismatches. Any discrepancy between the expected catalog-derived total and the amount actually charged should raise a flag for manual review, not just fail silently or succeed silently.

Closing Thoughts

Vulnerability research is, more often than not, unpaid and voluntary. A short, genuine "thank you" once an issue is fixed costs a company nothing and is the cheapest investment it can make in keeping researchers willing to report the next one, ignoring that costs more than it seems.

References

• OWASP, Testing for Business Logic
• CWE-602, Client-Side Enforcement of Server-Side Security