Pasos que se saltan o se repiten

Un flujo de compra se ve como una secuencia de pantallas: dirección, franja, pago, confirmación. Pero cada pantalla es una petición independiente que el cliente puede enviar cuando quiera, en el orden que quiera y tantas veces como quiera. Si el servidor deduce el paso actual de algo que controla el cliente (un campo oculto, un parámetro, una marca que se pone al abrir una pantalla), el orden de las pantallas deja de ser una regla y pasa a ser una sugerencia.

MITRE lo cataloga como CWE-841, la aplicación que no hace cumplir el flujo de comportamiento esperado, y la guía de pruebas web de OWASP le dedica una prueba propia dentro de las de lógica de negocio: intentar llegar al final de un proceso sin pasar por los pasos intermedios. La defensa es una máquina de estados en el servidor: cada objeto guarda su estado, y cada transición comprueba que parte del estado correcto y que su condición se cumplió de verdad.

Abre el laboratorio y lee CheckoutController.php en la carpeta mecato-pasos. Fíjate en qué comprueba confirmar y en qué momento se pone ese valor. Después cruza registro-checkout.txt con pagos-pasarela.txt: cada pedido confirmado con tarjeta debería tener su respuesta de la pasarela entre el paso de pago y la confirmación.

La marca de sesión no distingue entre un pago aprobado, uno rechazado y ninguno. Por eso el alcance no son solo los pedidos sin respuesta de la pasarela: también cuenta cualquiera que se confirmó con la pasarela diciendo que no. El que fue rechazado con un 409 no cuenta, porque nunca se confirmó.

El otro lado del mismo problema es un paso que debía ocurrir una sola vez y ocurre varias. MITRE tiene una entrada para eso, CWE-837: no hacer cumplir que una acción sea única. En Mecato el bono de bienvenida se aplica si la cuenta no tiene marcada la bienvenida, pero esa marca se pone en otro momento del flujo. Lee CuponService.php y EventServiceProvider.php y cruza con registro-cupones.txt. Por regla, cada cuenta recibe el bono una sola vez.

Los dos hallazgos comparten la raíz: el servidor decide con una señal que no coincide con el hecho que la regla protege. La confirmación mira una marca de navegación en vez del pago; el bono mira una marca que se pone días después de usarlo.