Metodología de lógica de negocio y race conditions

01Objetivo

Aprender a auditar la lógica propia de una aplicación (lo que nunca cubre un escáner automático porque no es un patrón conocido) y a detectar condiciones de carrera explotables.

02Teoría

Qué es un fallo de lógica de negocio

Es cualquier vulnerabilidad que no depende de una técnica de inyección, sino de que el flujo de la aplicación permite un estado que el diseño de negocio no previó: aplicar un cupón de un solo uso varias veces, completar un pedido sin pagar porque el paso de verificación de pago se puede saltar directamente a la URL de confirmación, cambiar el precio de un producto manipulando un campo que el frontend oculta pero el backend sigue aceptando desde el cliente.

Metodología para encontrar fallos de lógica de negocio

1. Mapea el flujo completo como una máquina de estados. Cada paso de un proceso multi-etapa (checkout, onboarding, recuperación de contraseña, aprobación de una solicitud) tiene un estado "antes" y "después". Pregunta: ¿qué pasa si salto directamente al estado "después" sin completar el paso intermedio?
2. Busca parámetros que el frontend calcula pero el backend no recalcula. Precio total, descuento aplicado, rol asignado tras una invitación: si el cliente los envía y el servidor los acepta sin recomputar desde cero en el backend, hay una vulnerabilidad de confianza indebida en el cliente.
3. Prueba el orden "incorrecto" de operaciones. ¿Se puede cancelar un pedido después de que ya se haya marcado como entregado? ¿Se puede usar un cupón después de que el carrito se haya vaciado y rellenado de nuevo?
4. Prueba los límites numéricos y de cantidad. Cantidades negativas, cero, o extremadamente altas en carritos, transferencias de puntos o solicitudes de reembolso, buscando que el backend calcule mal un total o permita un balance negativo que se trate como crédito.

Race conditions: la ventana de tiempo como vulnerabilidad

Una condición de carrera ocurre cuando dos operaciones que deberían ser atómicas (comprobar+actuar) se ejecutan en el orden equivocado porque el servidor procesa peticiones en paralelo sin bloqueo adecuado. El patrón más rentable en bug bounty: aplicar la misma acción de un solo uso varias veces en paralelo, antes de que la primera ejecución termine de actualizar el estado que la segunda comprobaría.

Casos clásicos:

• Canjear el mismo cupón de descuento N veces enviando N peticiones simultáneas.
• Retirar/transferir más saldo del disponible enviando varias peticiones de retiro a la vez, cada una viendo el saldo "antes" de que la anterior lo descuente.
• Crear más invitaciones o recursos gratuitos de los permitidos por cuenta.

Metodología de prueba: captura la petición de la acción en el proxy, y envíala en paralelo (no secuencial) usando la función de repetición concurrente del proxy (en Burp Suite, la pestaña Repeater con grupos de pestañas enviadas en el mismo instante, o la extensión Turbo Intruder para casos que requieren precisión de milisegundos). Si el resultado final muestra el efecto aplicado más veces de las que el límite de negocio permite, hay condición de carrera explotable.

03Lab asociado

Practica ambos patrones sobre GhostRace (tienda de artículos gaming de la serie Ghost, construida específicamente con tres condiciones de carrera reales) y sobre los mecanismos de recompensas/repetición de acciones de GhostFlix (donde una de las vulnerabilidades reales es precisamente una condición de carrera, junto a Mass Assignment y Match & Replace). El objetivo del lab es, para cada vulnerabilidad: (1) identificar la acción de un solo uso candidata, (2) capturar la petición, (3) reproducir el envío concurrente, (4) confirmar el efecto acumulado por encima del límite de negocio esperado.

04Resumen operativo

1. La lógica de negocio se audita mapeando el flujo como máquina de estados, no probando inyecciones.
2. Cualquier dato calculado en el cliente (precio, descuento, rol) y aceptado sin recálculo en servidor es sospechoso por defecto.
3. Las race conditions se cazan enviando la misma acción de un solo uso en paralelo, no en secuencia.
4. GhostRace y GhostFlix son los labs de referencia de este módulo.