Fallos de lógica de negocio

No son bugs de implementación como un XSS o un SQLi: el código funciona “como está escrito”, pero las reglas del negocio están mal pensadas o no se validan en servidor. El atacante no inyecta nada; usa la aplicación de formas que el diseñador no previó —saltarse pasos, repetir acciones, meter valores fuera de rango, combinar funciones legítimas— para conseguir algo que no debería. Son invisibles a los escáneres porque cada respuesta es “válida”.

Modelo de amenaza

El error raíz es confiar en el cliente para hacer cumplir una regla: el front valida el precio, el orden de los pasos, el límite de cantidad o el estado, y el servidor acepta lo que llegue. El atacante habla directo con la API, se salta la UI, y las suposiciones implícitas (“nadie mandaría cantidad negativa”, “siempre pasan por el paso 2 antes del 3”) se rompen.

Categorías frecuentes

Manipulación de precio/cantidad: cantidad negativa que reduce el total, precio enviado por el cliente, descuentos acumulables, redondeo a favor.
Saltar pasos del flujo: ir directo a /checkout/confirm sin pagar; acceder a /step3 sin completar step1/step2 (broken flow).
Abuso de cupones/descuentos: aplicar el mismo cupón N veces, combinar exclusivos, cupones de un solo uso reutilizados (ver también carreras).
Límites no aplicados en servidor: superar el máximo de intentos, de unidades, de transferencias.
Confianza en parámetros ocultos: campos hidden, cookies o JWT no verificados que marcan rol/precio/estado.
Validación inconsistente: el front valida, el back no; o dos endpoints validan distinto.

Red Team

Descubrimiento

Mapea el flujo completo de negocio (compra, registro, transferencia, suscripción) y anota cada suposición: ¿qué pasa si me salto este paso, repito aquel, mando el valor contrario?
Intercepta con Burp y manipula cada parámetro: precios, cantidades, IDs de estado, flags.
Compara lo que valida el front (JS) con lo que valida el back (habla directo con la API).

A mano: ejemplos

# cantidad negativa para invertir el total
POST /cart/add   {"item":"TV","qty":-3}        -> total baja

# precio controlado por el cliente
POST /checkout   {"item":"TV","price":1}

# saltar el pago
POST /order/confirm   {"orderId":123}          # sin pasar por /pay

# reusar cupón de un solo uso
POST /cart/coupon {"code":"SAVE50"}  x N

# cambiar el estado directamente
POST /order/update {"id":123,"status":"PAID"}

El patrón: lo que debería decidir el servidor lo manda el cliente, y el servidor no lo recalcula ni lo revalida.

Herramientas

Burp Suite — Repeater/Intruder para manipular y repetir pasos; el grueso es manual.
Diagramas del flujo (máquina de estados) para encontrar transiciones no previstas.

Impacto

Pérdidas económicas directas (comprar gratis/barato, retirar de más), fraude de cupones/puntos, acceso a funciones premium sin pagar, corrupción de datos de negocio.

Blue Team

Detección

Pedidos con totales anómalos, cantidades negativas, estados alcanzados sin el evento previo.
Mismo cupón/recurso de un solo uso aplicado varias veces.
Transiciones de estado imposibles según la máquina de estados.

Telemetría

Loguea cada transición de estado de negocio con su actor y valores; alerta sobre totales ≤ 0, saltos de paso y reusos.

Hardening

Valida y recalcula en servidor todo lo que importe: precio desde el catálogo, total desde los items, descuentos contra reglas; nunca confíes en valores del cliente.
Modela el flujo como máquina de estados y rechaza transiciones no permitidas (no se confirma sin pagar).
Aplica límites y unicidad en servidor (y en base de datos para condiciones de carrera).
Rangos y tipos estrictos (sin cantidades negativas, sin precios del cliente).
Pruebas de abuso en el diseño (“qué pasa si…”) y revisión de lógica, no solo escáner.

Respuesta

Reconcilia transacciones fraudulentas, añade las validaciones de servidor que faltaban, revisa histórico por abusos del mismo patrón.

CVEs y casos reales

La mayoría no son CVE: viven en bug bounties (HackerOne/Bugcrowd) por ser específicos de cada app.
Starbucks / plataformas de puntos — duplicación de saldo por lógica + carrera.
Múltiples e-commerce — compras a precio manipulado por confiar en el precio del cliente.
OWASP WSTG y PortSwigger documentan patrones y labs reproducibles (business logic vulnerabilities).

Checklist de prueba

¿El servidor recalcula precio/total/descuento o confía en el cliente?
¿Se puede saltar un paso del flujo (pagar, verificar)?
¿Se aceptan cantidades negativas o fuera de rango?
¿Los límites (intentos, unidades, cupones) se aplican en servidor?
¿Se puede cambiar el estado directamente (status=PAID)?
¿Hay parámetros ocultos (hidden/cookie/JWT) que deciden rol/precio?
¿Front y back validan lo mismo? (habla directo con la API)