Vulnerabilidades de lógica de negocio: guía pentest

Las vulnerabilidades de lógica de negocio son fallos en el diseño o la implementación de los flujos de una aplicación que permiten a un atacante usar funcionalidad legítima de forma no prevista. No hay un payload malformado ni una inyección: cada petición es sintácticamente válida y, vista de forma aislada, parece el uso normal de la aplicación. Por eso son la clase de vulnerabilidad que mejor separa un pentesting manual de un escaneo automatizado, y la razón por la que un escáner puede devolver "sin hallazgos" sobre una aplicación que regala productos, duplica saldos o expone pedidos ajenos.

Esta guía explica qué es exactamente un fallo de lógica de negocio, por qué SAST y DAST no lo ven, la taxonomía clásica con ejemplos concretos de e-commerce y fintech, cómo se ejecuta la prueba manual siguiendo OWASP WSTG, los patrones de remediación y por qué un pentest manual anual es el control que exigen NIS2, DORA y PCI DSS.

Qué es una vulnerabilidad de lógica de negocio

Una vulnerabilidad de lógica de negocio es un fallo en las reglas que gobiernan un proceso, no en la sintaxis de una petición. La aplicación hace exactamente lo que el código le indica, pero ese código asume una secuencia, un rango de valores o una identidad que el atacante no respeta. El ejemplo canónico: una tienda que confía en el campo price enviado por el navegador y acepta un pedido con price negativo, generando un abono a favor del cliente.

La diferencia con una vulnerabilidad técnica (inyección SQL, XSS, SSRF) es que aquí no existe una firma. No hay una cadena maliciosa que un motor de reglas pueda reconocer. El "exploit" es una secuencia de peticiones perfectamente formadas que rompen una invariante del negocio: un cupón de un solo uso aplicado tres veces, un pedido ajeno consultado por su identificador, un saldo retirado dos veces en paralelo.

Por qué SAST, DAST y los escáneres no las detectan

Las tres capas de automatización de AppSec fallan aquí por la misma razón de fondo: no conocen las reglas de tu negocio.

• SAST analiza el código en busca de patrones peligrosos (flujo de datos hacia un sink de SQL, deserialización insegura). Un fallo de lógica no tiene sink peligroso: el código que aplica un descuento es correcto en sí mismo, el problema es que no comprueba si ese descuento ya se consumió.
• DAST lanza payloads y busca anomalías en la respuesta (errores, reflejos, tiempos). Un precio negativo devuelve 200 OK con un JSON coherente, así que el escáner lo da por válido. No sabe que un precio negativo no debería existir.
• Los escáneres de vulnerabilidades (Nuclei, Acunetix, Burp Scanner) trabajan con firmas y comprobaciones genéricas. La lógica de negocio es única de cada aplicación, así que no hay plantilla que reutilizar.

Un detalle revelador: estos fallos casi nunca reciben un CVE, precisamente porque son propios de cada aplicación y no de un producto reutilizable. No aparecen en las bases de datos de vulnerabilidades, lo que refuerza que sólo un analista humano que entienda el proceso puede encontrarlos.

Taxonomía de fallos de lógica con ejemplos reales

Manipulación de precio y cantidad

El servidor confía en valores que deberían calcularse del lado servidor. Modificar price, aplicar una cantidad negativa que convierte el pago en un ingreso, o cambiar la divisa a una de menor valor son variantes de la misma raíz: la validación de datos vive en el cliente. Es el hallazgo más frecuente en carritos y pasarelas.

Abuso de cupones y descuentos

Un cupón de un solo uso que puede reutilizarse porque no se marca como consumido, varios cupones apilables que no debían combinarse, o el mismo código aplicado en paralelo antes de que el sistema lo invalide. En fintech, el equivalente es el bono de bienvenida reclamado varias veces desde cuentas encadenadas.

IDOR sobre pedidos y recursos

Cuando un endpoint como GET /api/orders/1042 devuelve el pedido de otro cliente por carecer de autorización a nivel de objeto, hablamos de un IDOR o broken access control, la clase de fallo más habitual en APIs. Basta incrementar el identificador para leer facturas, direcciones o datos de pago ajenos.

Condiciones de carrera en transacciones

Enviar dos peticiones de retirada o de canje casi simultáneas puede saltarse la comprobación de saldo si la lectura y la escritura no son atómicas (un TOCTOU clásico). Es el mecanismo detrás del doble gasto de una tarjeta regalo o de superar un límite de compra. Lo tratamos en profundidad en race conditions en aplicaciones web.

Mass assignment y escalada de rol

Un endpoint que vincula todo el cuerpo de la petición al modelo de datos permite enviar campos ocultos. Un PATCH /api/users/me con {"role":"admin"} o {"isVerified":true} en el JSON puede otorgar privilegios que la interfaz nunca expone. Es el API6 del OWASP API Security Top 10.

Bypass de flujos multi-paso

Los procesos de varias etapas (carrito, envío, pago, confirmación) asumen un orden. Si es posible navegar directamente a la URL de confirmación sin pasar por el pago, o forzar el estado del pedido a "pagado" mediante un parámetro, el flujo se rompe. Aparece en registros con verificación por correo, procesos KYC y checkout.

Falta de límite de uso (anti-automatización)

Un código OTP de seis dígitos sin límite de intentos es fuerza bruta trivial. Sin control de frecuencia, un atacante enumera tarjetas regalo, prueba credenciales filtradas o agota tokens de recuperación de contraseña. Es el WSTG-BUSL-05 y el API4 (consumo de recursos sin restricción).

Cómo se auditan: OWASP WSTG paso a paso

La Guía de Pruebas de Seguridad Web de OWASP (WSTG) dedica su sección 4.10 a la lógica de negocio, con nueve pruebas que van de la validación de datos (WSTG-BUSL-01) a la circunvención de flujos (WSTG-BUSL-06) y los límites de uso de una función (WSTG-BUSL-05). No es un escaneo, es un proceso dirigido por hipótesis:

1. Modelar las reglas de negocio. Antes de tocar la aplicación, el analista documenta las invariantes: un pedido no puede tener precio negativo, un cupón se usa una vez, un usuario sólo ve sus recursos. Sin este modelo no hay casos de abuso que probar.
2. Mapear el flujo legítimo. Se recorre el proceso completo con el proxy activo (Burp Suite) para capturar cada petición y entender la máquina de estados real.
3. Construir los casos de abuso. Para cada invariante se diseña una violación: alterar el valor en Repeater, reordenar los pasos, repetir una petición con la sesión de otro usuario, o lanzar peticiones concurrentes.
4. Probar las carreras. Con Turbo Intruder y el ataque de un solo paquete (single-packet attack sobre HTTP/2) se envían peticiones casi simultáneas para forzar TOCTOU en pagos y canjes.
5. Verificar y documentar. Cada hallazgo se acompaña de prueba de concepto reproducible: request, response y pasos exactos, con severidad CVSS justificada por el impacto en el negocio.

Este trabajo forma parte de cualquier pentesting de aplicaciones web serio y, cuando el producto expone servicios, del pentesting de APIs REST y GraphQL.

Patrones de remediación

La corrección casi siempre consiste en trasladar la confianza del cliente al servidor:

• Invariantes del lado servidor. Recalcular el precio desde el catálogo, validar que la cantidad es mayor o igual a uno y rechazar cualquier estado no permitido. El cliente nunca es fuente de verdad.
• Idempotencia. Añadir una clave de idempotencia (cabecera Idempotency-Key) a los endpoints de pago para que un reenvío no cobre ni acredite dos veces.
• Máquinas de estado explícitas. Modelar el flujo como una FSM que rechace transiciones no válidas desde el estado actual (no se puede pasar a "pagado" sin pasar por "pago autorizado").
• Operaciones atómicas. Usar transacciones de base de datos, SELECT ... FOR UPDATE o bloqueo optimista con columna de versión para eliminar las condiciones de carrera.
• Lista blanca de campos. Vincular sólo los atributos permitidos mediante DTOs, nunca el cuerpo completo al modelo, para cerrar el mass assignment.
• Anti-automatización. Límite de frecuencia por cuenta y por IP, CAPTCHA en endpoints sensibles, invalidación de tokens de un solo uso y backoff exponencial.

Lógica de negocio y cumplimiento: por qué el pentest manual anual es obligatorio

Como estos fallos dependen del contexto de cada negocio, ninguna herramienta ni programa de bug bounty los cubre de forma fiable: hace falta un analista que entienda las reglas del producto. Ese es exactamente el control que exigen los marcos vigentes. NIS2 obliga a medidas de gestión de riesgos con pruebas de eficacia periódicas. DORA impone a las entidades financieras pruebas dirigidas por amenazas (TLPT), donde la lógica transaccional es objetivo prioritario. PCI DSS 4.0 requiere pruebas de penetración periódicas sobre las aplicaciones que procesan pagos, un terreno donde el abuso de precio y de cupones es el riesgo dominante. Puedes ver el encaje completo en el OWASP Top 10 para empresas.

La conclusión práctica: un escaneo continuo detecta lo barato y automatizable, pero un pentest manual anual, con retest tras cada cambio en autenticación, autorización o pagos, es el único ejercicio que evidencia estos controles y encuentra los fallos que de verdad cuestan dinero.

Preguntas frecuentes

¿En qué se diferencia un fallo de lógica de negocio de una vulnerabilidad técnica?

Una vulnerabilidad técnica (inyección SQL, XSS) tiene una firma reconocible y se detecta con automatización. Un fallo de lógica no: la petición es válida y sólo es maliciosa en el contexto de una regla de negocio que la herramienta desconoce. Por eso requiere análisis humano.

¿Por qué mi escáner no encuentra estos fallos?

Porque los escáneres buscan patrones genéricos y anomalías en la respuesta. Un precio negativo o un cupón reutilizado devuelven respuestas correctas (200 OK), sin error ni reflejo que disparar una alerta. La herramienta no conoce las invariantes de tu aplicación.

¿Qué herramientas se usan para probar lógica de negocio?

Principalmente Burp Suite (Repeater para tamper manual, Intruder y la extensión Turbo Intruder para condiciones de carrera con single-packet attack). El grueso del valor está en el criterio del analista, no en la herramienta: primero se modelan las reglas y luego se diseñan los casos de abuso.

¿Las condiciones de carrera son fallos de lógica de negocio?

Sí. Una carrera que permite gastar dos veces un saldo o canjear varias veces una tarjeta regalo es un abuso de la lógica transaccional. Se mitiga con operaciones atómicas e idempotencia. Lo desarrollamos en nuestro artículo sobre race conditions.

¿Con qué frecuencia debo auditar la lógica de negocio?

Como mínimo una vez al año, y siempre tras un cambio significativo en pagos, cupones, roles o cualquier flujo multi-paso. PCI DSS, NIS2 y DORA marcan ese ritmo anual para las aplicaciones que procesan datos o transacciones sensibles.