[ES] Stock Depletion via Ticket Quantity Bypass and Payment-Mode Manipulation (IDOR)

Nota de Censura: Para proteger absolutamente la identidad del programa afectado, todos los identificadores, variables, tiempos de gracia, rutas de API y mecánicas internas han sido abstraídos o reemplazados por conceptos genéricos (ej. METHOD_A, /checkout/gateway). Cualquier similitud con una plataforma real es puramente estructurada para el entendimiento teórico del fallo.

Este writeup documenta un fallo crítico de lógica de negocio (Business Logic Error - CWE-840) descubierto en el flujo de pagos de una plataforma de comercio electrónico orientada a eventos.

La explotación encadenaba una omisión de los límites de sesión del carrito con la manipulación de parámetros (Parameter Tampering / IDOR) en la pasarela, permitiendo a un atacante reservar y agotar el 100% del stock disponible de un servicio sin la necesidad de procesar ningún pago real.

Arquitectura y Deficiencias

El flujo legítimo de reserva y pago establecía los siguientes pasos:

1. El usuario añade la cantidad deseada al carrito (el frontend y backend debían limitar este número a una pequeña fracción del total).
2. Se inicia la fase de facturación, bloqueando el stock temporalmente.
3. El usuario completa el pago (ej. insertando una tarjeta de crédito válida).
4. El sistema emite el servicio/ticket de forma definitiva.

Lamentablemente, el diseño padecía de dos problemas severos:

1. Omisión de Límite de Carrito: Un endpoint secundario destinado a sincronizar artículos (/api/v2/basket/modify_quantity) delegaba toda la validación de cantidades máximas al Frontend. A nivel de servidor, se aceptaba cualquier número inyectado en la petición, permitiendo añadir la totalidad del inventario de un evento en una única sesión.
2. Confianza Ciega en Parámetros de Pago: Tras fijar el carrito, el sistema confirmaba la orden enviando el identificador del método de facturación en una petición POST final al endpoint de la pasarela (/api/v2/transaction/init). Este endpoint procesaba el identificador (gw_type) sin verificar si el usuario tenía privilegios o si el método de pago estaba autorizado para ese evento específico.

El Vector de Ataque (PoC)

El objetivo era vaciar el inventario indefinidamente saltándose la verificación bancaria. El ataque se dividía en tres fases:

1. Inyección Masiva en la Cesta

Se enviaba una petición HTTP manipulada al endpoint /api/v2/basket/modify_quantity, inyectando una cantidad que igualaba el aforo máximo disponible. Al no existir una validación estricta por sesión, la cesta retenía todo el inventario de la plataforma.