Las vulnerabilidades de lógica de negocio son las que pasan completamente desapercibidas para los escáneres. Sin CVE, sin entrada en exploit-db, sin plantilla de Nuclei. Solo una brecha entre lo que la aplicación pretende hacer y lo que realmente hace cuando la presionas desde un ángulo inesperado.

También son algunos de los hallazgos más valiosos que puedes reportar. Alto impacto en el negocio, difíciles de detectar automáticamente, y con frecuencia llevan años en producción porque nadie pensó en probarlas.

Esta guía cubre cómo encontrarlas, cómo explotarlas y cómo se ven los ataques de lógica de negocio en la práctica.

¿Qué es una Vulnerabilidad de Lógica de Negocio?

Una vulnerabilidad de lógica de negocio es un fallo en el diseño o implementación del flujo de trabajo previsto de una aplicación — no un problema clásico de inyección o corrupción de memoria, sino un caso donde las propias reglas de la aplicación pueden ser abusadas.

Ejemplos clásicos:

  • Aplicar un cupón de descuento más de una vez
  • Comprar artículos a precios negativos
  • Saltarse pasos de pago en un proceso de pago en múltiples etapas
  • Retirar más dinero del que tienes en tu saldo
  • Acceder a los datos de otro usuario manipulando un ID de pedido
  • Eludir límites de velocidad modificando parámetros de solicitud
  • Explotar condiciones de carrera durante transacciones concurrentes

Lo que hace que estos fallos sean peligrosos es que la aplicación se comporta exactamente como fue codificada — la lógica en sí misma está rota.

Por Qué los Fallos de Lógica de Negocio se Reportan Poco

Los escáneres automatizados son inútiles aquí. No hay error SQL que detectar, no hay payload de XSS que inyectar, no hay excepción del lado del servidor que capturar. Encontrarlos requiere:

  1. Entender el flujo de trabajo previsto — tienes que saber lo que la aplicación debería hacer
  2. Desviación creativa — probar qué ocurre cuando no sigues el camino esperado
  3. Solicitudes encadenadas — frecuentemente la vulnerabilidad solo aparece a través de múltiples pasos

La mayoría de los pentesters dedican el 90% de su tiempo a ataques de inyección. Los fallos de lógica de negocio se quedan ahí acumulando polvo.

Categorías Comunes de Vulnerabilidades de Lógica de Negocio

1. Manipulación de Precios y Cantidades

La aplicación confía en valores proporcionados por el usuario para precios, cantidades o descuentos.

Ataque:

POST /cart/add HTTP/1.1
Host: tienda.objetivo.com
Content-Type: application/json

{
  "item_id": "SKU-4421",
  "quantity": -1,
  "price": -99.99
}

Si el backend usa el campo price proporcionado por el cliente, acabas de crear crédito en la tienda al añadir un artículo con precio negativo.

Qué probar:

  • Cantidades negativas en el carrito
  • Precios negativos
  • Artículos a precio cero con códigos promocionales
  • Desbordamiento de enteros en cantidades (ej., quantity=2147483647)
  • Modificar campos ocultos del formulario como price, total, discount

2. Abuso de Cupones y Descuentos

La lógica de descuentos es notoriamente defectuosa. Las aplicaciones frecuentemente validan la presencia de un cupón pero no sus restricciones de reutilización.

Patrones de ataque:

  • Aplicar el mismo cupón múltiples veces antes de que se complete el pago
  • Aplicar múltiples cupones diferentes que no están diseñados para acumularse
  • Usar un cupón para una categoría de producto a la que no aplica
  • Condición de carrera: enviar el proceso de pago dos veces simultáneamente con el mismo cupón de un solo uso

Enfoque con Burp Suite: Usa el Repeater para repetir las solicitudes de aplicación de cupones en rápida sucesión. Verifica si el descuento se acumula.

POST /promo/apply HTTP/1.1
Host: objetivo.com

code=SAVE50&order_id=8821

Envía 5 solicitudes simultáneas mediante Burp Intruder (payload nulo, 5 iteraciones, hilos concurrentes) y observa si el descuento se aplica múltiples veces.

3. Saltar Pasos del Flujo de Trabajo

Los procesos de múltiples pasos (pago, restablecimiento de contraseña, incorporación) a menudo carecen de validación de estado del lado del servidor. La aplicación asume que completaste el Paso 2 antes del Paso 3, pero no lo verifica.

Ejemplo — bypass de pago:

  1. Iniciar proceso de pago → obtener ID de pedido ORD-9921
  2. Saltar el paso de pago por completo
  3. Navegar directamente a: GET /checkout/confirm?order_id=ORD-9921&status=paid

Si la página de confirmación procesa el pedido sin verificar que realmente se cobró el pago, has completado una compra gratuita.

Qué mapear:

Paso 1: /checkout/start → establece order_id
Paso 2: /checkout/payment → llama al procesador de pago
Paso 3: /checkout/confirm → marca el pedido como completado

Prueba saltar directamente del Paso 1 al Paso 3. Si el Paso 3 solo verifica que existe un order_id (no que el pago se realizó), el paso es saltable.

4. Escalada de Cuentas y Privilegios mediante Lógica

No es IDOR (eso es diferente) — aquí se manipula la lógica alrededor de niveles de cuenta, suscripciones o roles.

Ejemplos:

  • Registrarse para una prueba gratuita → se envía una solicitud de degradación a /api/account/downgrade → interceptarla y enviar parámetros de actualización en su lugar
  • Comprar el nivel básico → modificar plan_id durante la devolución de llamada post-pago
  • Abuso de referencias: crear cuentas con el mismo correo usando trucos +etiqueta ([email protected], [email protected]) para auto-referirse

Bypass de suscripción:

POST /api/billing/webhook HTTP/1.1
Host: saas-objetivo.com
Content-Type: application/json

{
  "event": "subscription.updated",
  "plan": "enterprise",
  "user_id": "TU_USER_ID",
  "status": "active"
}

Si el endpoint del webhook de facturación no está correctamente autenticado (sin verificación de firma), puedes dispararlo tú mismo y actualizar tu propia cuenta.

5. Condiciones de Carrera

Las condiciones de carrera en la lógica de negocio son devastadoras en aplicaciones financieras. El clásico: retirar los mismos fondos dos veces antes de que se actualice el saldo.

La ventana TOCTOU (Time-of-Check to Time-of-Use):

Hilo 1: Verificar saldo ($100) → saldo OK
Hilo 2: Verificar saldo ($100) → saldo OK
Hilo 1: Debitar $100 → saldo = $0
Hilo 2: Debitar $100 → saldo = -$100 (permitido)

Herramientas para pruebas de condiciones de carrera:

Las Solicitudes Paralelas de Burp Suite Pro (añadidas en 2023) están diseñadas específicamente para esto:

  1. Intercepta la solicitud objetivo (aplicar cupón, transferencia, compra)
  2. Clic derecho → Send to Repeater
  3. Duplica la pestaña 5-10 veces
  4. Usa Send group (parallel) — todas las solicitudes se disparan simultáneamente

Para ataques de paquete único (eliminando el jitter de red):

  • Activa “Send group (single-packet attack)” en la configuración de Burp Repeater
  • Fuerza que todas las solicitudes HTTP/2 lleguen al servidor en un único segmento TCP
# Prueba manual de condición de carrera con Python
import threading
import requests

url = "https://objetivo.com/api/coupon/apply"
headers = {"Authorization": "Bearer TU_TOKEN", "Content-Type": "application/json"}
payload = {"code": "PROMO50", "order_id": "ORD-1234"}

def aplicar_cupon():
    r = requests.post(url, json=payload, headers=headers)
    print(r.status_code, r.json())

hilos = [threading.Thread(target=aplicar_cupon) for _ in range(10)]
for h in hilos:
    h.start()
for h in hilos:
    h.join()

6. Confianza Excesiva en Datos del Lado del Cliente

Las aplicaciones que realizan validación en el lado del cliente (JavaScript) y confían en el resultado del lado del servidor son completamente vulnerables.

Manifestaciones comunes:

  • Campos de formulario ocultos con precios, IDs de usuario o indicadores de privilegios
  • Claims de JWT que no deberían ser modificables
  • Valores de cookies que controlan el nivel de acceso (admin=false → admin=true)
  • Tokens de almacenamiento local decodificados del lado del cliente para determinar permisos

Qué buscar:

  • Cualquier cuerpo POST que contenga role, admin, plan, tier, price, discount
  • Cookies siendo analizadas por la lógica de la aplicación (no solo gestión de sesión)
  • JSON Web Tokens donde el claim role o permissions se establece del lado del cliente

7. Validación Insuficiente en Transiciones de Estado

Algunas aplicaciones permiten cambios de estado en ambas direcciones cuando solo se debería permitir una dirección.

Ejemplo — abuso de reembolsos:

  1. Comprar artículo → obtener order_id=ORD-5521
  2. Solicitar reembolso → dinero devuelto, pedido marcado como refunded
  3. Modificar el estado de vuelta: PATCH /api/orders/ORD-5521 con {"status": "delivered"}

Si la aplicación permite cambios de estado arbitrarios mediante la API y no valida la ruta de transición, ahora tienes un artículo entregado y un reembolso.

Mapeo de máquina de estados:

pendiente → pagado → procesando → enviado → entregado
                                           ↗
                              reembolso_solicitado → reembolsado

Prueba: ¿Puedes transicionar directamente de cualquier estado a cualquier otro? ¿Puedes ir hacia atrás (entregado → pendiente)?

Metodología: Cómo Cazar Fallos de Lógica de Negocio

Paso 1: Mapear Cada Flujo de Trabajo

Antes de probar cualquier cosa, mapea lo que la aplicación pretende hacer:

  1. Navega la aplicación como un usuario legítimo — haz todo lo que la interfaz te permita
  2. Captura cada solicitud en Burp Proxy
  3. Agrupa las solicitudes en flujos de trabajo: registro, pago, restablecimiento de contraseña, funciones de administrador
  4. Para cada flujo de trabajo, anota la secuencia de solicitudes y los parámetros que intercambian

Paso 2: Identificar Límites de Confianza

Para cada parámetro pregunta: ¿Quién debería controlar este valor?

  • Si el servidor debería establecerlo → prueba si el cliente puede sobreescribirlo
  • Si se establece una vez y se referencia posteriormente → prueba si puede cambiarse a mitad del flujo
  • Si se valida una vez → prueba si se puede omitir la validación manipulando la secuencia

Paso 3: Probar Cada Suposición

Para cada flujo de trabajo, el desarrollador hizo suposiciones. Tu trabajo es violar cada una:

Suposición del DesarrolladorTu Prueba
Los usuarios completan los pasos en ordenSalta pasos, repite pasos, invierte el orden
Las cantidades son positivasEnvía cantidades negativas, cero, fraccionarias
Los precios vienen del servidorModifica cualquier campo de precio en tránsito
Los tokens de un solo uso se usan una vezEnvía el mismo token dos veces simultáneamente
Los roles se establecen en el inicio de sesiónModifica parámetros role/admin en cada solicitud
La validación ocurre del lado del servidorDeshabilita JavaScript, modifica verificaciones del lado del cliente

Paso 4: Probar Casos Límite

  • Límites de enteros: 0, -1, 2147483647 (int max), 2147483648 (desbordamiento), null
  • Cadenas vacías versus campos ausentes
  • Unicode en campos normalmente ASCII
  • Valores extremadamente largos
  • Parámetros repetidos (?id=1&id=2 — ¿cuál usa la aplicación?)

Paso 5: Encadenar Hallazgos

Las vulnerabilidades de lógica de negocio frecuentemente solo importan cuando se encadenan:

  • IDOR (acceder al pedido de otro usuario) + manipulación de cupón = robo de cupón
  • Condición de carrera + cupón = descuento ilimitado
  • Salto de flujo + manipulación de precio = compra gratuita

Ejemplos Reales de Ataques de Lógica de Negocio

La Condición de Carrera de Shopify (2022)

Investigadores descubrieron que el endpoint de canje de tarjetas de regalo de Shopify era vulnerable a condiciones de carrera. Enviando solicitudes paralelas, los atacantes podían canjear una sola tarjeta de regalo múltiples veces antes de que el saldo se marcara como cero.

Solución: Implementar bloqueos a nivel de base de datos o transacciones atómicas con control de concurrencia optimista.

Manipulación de Precios Negativos en Booking.com

Las versiones tempranas de las aplicaciones de reserva de viajes (incluyendo importantes OTAs) no validaban que los campos de cantidad permanecieran positivos. Cantidades negativas × precio positivo = total negativo, que a veces se procesaba como un crédito.

Bypass de Autenticación de Dos Factores mediante Salto de Flujo

Una clase bien documentada de fallos en implementaciones 2FA: la aplicación te envía a /dashboard después de /2fa/verify, pero el dashboard solo verifica una cookie de sesión válida (establecida después de la autenticación con contraseña) — no si 2FA fue realmente completado. Navegar directamente a /dashboard omite el paso 2FA por completo.

/login → POST credenciales → cookie de sesión establecida → /2fa → POST código 2FA → /dashboard
                                                                                      ↑
                                                                     Navegar aquí directamente

Configuración de Burp Suite para Pruebas de Lógica de Negocio

Herramientas de Burp Suite Pro para pruebas de lógica de negocio:

Proxy + Logger:

  • Habilita todo el registro en Proxy → Options
  • Usa el logger de Burp para reproducir flujos completos

Repeater para Pruebas Manuales:

  • Clic derecho en cualquier solicitud → Send to Repeater
  • Modifica parámetros uno a la vez y observa las diferencias
  • Encadena pestañas del Repeater para flujos de trabajo de múltiples pasos

Intruder para Automatización:

  • Ataque cluster bomb para pruebas de múltiples parámetros
  • Payload nulo para pruebas de condición de carrera (solicitudes concurrentes)

Sequencer:

  • Prueba la predictibilidad de tokens (IDs de pedido, IDs de sesión, tokens CSRF)
  • IDs predecibles = potencial de IDOR

Extensiones (BApp Store):

  • Autorize — pruebas automáticas de escalada de privilegios
  • Param Miner — descubrir parámetros ocultos
  • Turbo Intruder — solicitudes paralelas de alta velocidad para condiciones de carrera
  • Logger++ — registro mejorado con filtros

Entorno de práctica (despliega un VPS en la nube para pruebas aisladas):

  • Vultr — $6/mes, desplegado en segundos
  • DigitalOcean — droplets gestionados con aplicaciones de un clic

Defensa: Cómo Corregir las Vulnerabilidades de Lógica de Negocio

Entender las defensas te hace un mejor atacante — sabrás dónde están las brechas.

Gestión de Estado del Lado del Servidor

Nunca confíes en el estado proporcionado por el cliente. El servidor debe:

  • Mantener el estado del flujo de trabajo en la base de datos, no en campos ocultos o cookies
  • Hacer cumplir transiciones de estado válidas: pendiente → pagado → enviado solo, no saltos arbitrarios
  • Validar el estado completo en cada solicitud, no solo el paso actual

Transacciones Atómicas para Operaciones Financieras

# Incorrecto: verificar luego actuar (vulnerable a TOCTOU)
saldo = obtener_saldo(user_id)
if saldo >= monto:
    debitar(user_id, monto)

# Correcto: actualización atómica con verificación
resultado = db.execute(
    "UPDATE cuentas SET saldo = saldo - ? WHERE user_id = ? AND saldo >= ?",
    (monto, user_id, monto)
)
if resultado.rowcount == 0:
    raise FondosInsuficientesError()

Validación de Entrada — Todos los Valores, Del Lado del Servidor

  • Valida todos los valores numéricos: positivos, dentro de límites, tipo correcto
  • Rechaza solicitudes con cantidades o precios fuera de rango
  • Nunca aceptes precios del cliente — siempre consúltalos del lado del servidor
  • Tokens de un solo uso: márcalos como usados de forma atómica, antes de devolver el éxito

Verificación de Firma de Webhooks

import hmac
import hashlib

def verificar_webhook(cuerpo_payload, firma_header, secreto):
    esperado = hmac.new(
        secreto.encode(),
        cuerpo_payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(esperado, firma_header)

Objetivos de Práctica

La mejor manera de aprender pruebas de lógica de negocio es romper aplicaciones intencionalmente vulnerables:

PortSwigger Web Security Academy — tiene una serie dedicada de laboratorios de Vulnerabilidades de Lógica de Negocio . Gratuito. Esencial.

DVWA (Damn Vulnerable Web Application):

docker run -d -p 80:80 vulnerables/web-dvwa

Juice Shop (OWASP):

docker run -d -p 3000:3000 bkimminich/juice-shop

Accede a Juice Shop en http://localhost:3000 — incluye desafíos de lógica de negocio en su sistema de puntuación.

Para un laboratorio en la nube (en lugar de local):

DigitalOcean te permite desplegar un droplet de $6, instalar una aplicación vulnerable y eliminarlo cuando termines. Aislamiento limpio, sin riesgo para la red doméstica.

Conclusiones Clave

  • Las vulnerabilidades de lógica de negocio requieren pruebas manuales — los escáneres no las encontrarán
  • Mapea los flujos de trabajo antes de probar: entiende la intención, luego viola las suposiciones
  • Enfócate en transiciones de estado, entradas numéricas, flujos de múltiples pasos y operaciones concurrentes
  • Las condiciones de carrera en flujos financieros son de severidad crítica — pruébalas con la función de solicitudes paralelas de Burp
  • La mejor defensa es la gestión de estado del lado del servidor con operaciones atómicas

Guías Relacionadas

¿Necesitas un informe de pentesting profesional para tu próximo compromiso? CipherWrite ofrece redacción técnica enfocada en seguridad — informes, whitepapers y resúmenes ejecutivos escritos por profesionales.