Fallo de lógica de negocio (Business logic flaw)
En seguridad de aplicaciones, un fallo de lógica de negocio es un defecto en lo que la aplicación permite, no en cómo está programada. Todas las peticiones están bien formadas y todos los controles técnicos funcionan; el atacante se limita a usar el flujo de trabajo en un orden, una cantidad o una combinación que los diseñadores nunca contemplaron, y la aplicación acepta.
Cómo funciona
No hay ninguna función insegura que buscar con un grep ni ninguna entrada malformada que rechazar, porque no hay nada malformado. El atacante estudia qué intenta conseguir la aplicación y luego rompe una premisa que la propia aplicación nunca llegó a escribir: que un paso ocurre antes que otro, que un valor no puede ser negativo, que un descuento se usa una sola vez, que el precio que envía el cliente coincide con el del catálogo, que una devolución no puede superar al pago, que dos peticiones no van a llegar en el mismo instante.
Encontrarlos es un ejercicio de modelado. Se enumeran los estados en los que puede estar un objeto, las transiciones que ofrece la interfaz, y después se intentan las transiciones que la interfaz no ofrece pero el servidor sigue aceptando. Por eso la entrada útil es la documentación, una sesión guiada con el responsable de producto y el threat modelling, no una lista de payloads.
Qué sale mal
Estos fallos sobreviven porque los escáneres no los ven. Un escáner reconoce patrones que están mal en general. Que un pedido pueda salir antes de que el pago se confirme solo está mal en el contexto de este negocio, y ninguna herramienta tiene ese contexto. Este es el argumento medible más claro a favor de las pruebas manuales: las categorías que una herramienta cubre bien y las que no puede cubrir en absoluto son conjuntos distintos, y esta cae entera en el segundo.
Lo que recuperamos en la práctica es dinero y privilegio. Aplicar un cupón de forma concurrente para que la comprobación de canje pase dos veces es una race condition en la lógica. Saltarse el paso del pago pidiendo directamente la ruta de confirmación. Cambiar un identificador en un flujo de varios pasos para que el último actúe sobre el objeto de otra persona, que es donde esto se cruza con IDOR. Completar un registro omitiendo el paso de verificación del correo, que acaba en apropiación de cuenta.
Dónde aparece esto en una auditoría
El hallazgo se escribe como una secuencia de peticiones, en orden, con el estado en que queda el registro, porque aquí una sola petición no demuestra nada. Enunciamos en lenguaje llano la premisa que se rompió, porque es lo que la corrección tiene que restaurar, y la corrección es casi siempre una comprobación en servidor en una transición concreta, no una validación de entrada. La severidad se mide por lo que vale el fallo cada vez que se ejecuta y por si se puede repetir. Esto forma parte de por qué nuestro pentesting web se hace a mano y no con escáner.