[EN] Exploiting Business Logic: Inventory Depletion via Parameter Tampering

Censorship Note: To strictly protect the identity of the affected program, all identifiers, variables, grace periods, API paths, and internal mechanics have been abstracted or replaced with generic concepts (e.g., METHOD_A, /checkout/gateway). Any resemblance to a real-world platform is purely structural for the theoretical understanding of the flaw.

This writeup documents a critical Business Logic Error (CWE-840) discovered in the payment flow of an event-driven e-commerce platform.

The exploitation chained a session cart limit bypass with parameter tampering at the payment gateway level, allowing an attacker to reserve and entirely deplete an event's available stock without processing any real payment.

Architecture and Deficiencies

The legitimate reservation and payment flow dictated the following steps:

1. The user adds the desired quantity to their cart (both frontend and backend should limit this to a small fraction of the total).
2. The billing phase initiates, temporarily locking the requested stock.
3. The user completes the payment out-of-band (e.g., inserting a valid credit card).
4. The system issues the ticket/service permanently.

Unfortunately, the platform suffered from two severe design flaws:

1. Cart Limit Omission: A secondary endpoint meant for generic item synchronization (/api/v2/basket/modify_quantity) delegated all maximum quantity validations to the frontend. Server-side, it accepted any numerical value injected into the payload, allowing a single session to swallow the entirety of a venue's inventory.
2. Blind Trust in Payment Parameters: After securing the cart, the system confirmed the order by sending the billing method identifier in a final POST request to the gateway handler (/api/v2/transaction/init). This endpoint parsed the identifier (gw_type) without validating if the user was privileged, or if the specified payment method was authorized for that specific event.

The Attack Vector (PoC)

The goal was to drain the inventory indefinitely by skipping banking verifications. The attack unfolded in three phases:

1. Massive Cart Injection

A manipulated HTTP request was pushed to the /api/v2/basket/modify_quantity endpoint, injecting an amount matching the maximum available capacity. Lacking strict session-based validation, the basket retained the platform’s whole inventory.