Pasos del flujo y carreras de condición

El diseño de Despensa Andina declara cuatro pasos —carrito, envío, pago, confirmación— y lo que cada uno exige del anterior. Para el servidor, sin embargo, cada paso es una dirección más: si no comprueba el estado de la sesión, responde a quien la pida en el orden que sea. La guía de pruebas de OWASP lo cubre en WSTG-BUSL-06, «Testing for the Circumvention of Work Flows», y el catálogo de debilidades lo recoge como CWE-841, «Improper Enforcement of Behavioral Workflow».

La señal en los registros es la secuencia de peticiones de una misma sesión: un paso final que aparece sin que haya aparecido el paso que lo habilita. La corrección es una máquina de estados en el servidor: cada paso comprueba lo que exige, aunque la persona haya llegado por una dirección escrita a mano.

Abre el laboratorio. La tabla de sesiones de compra tiene, para cada petición, si la sesión tenía un pago aprobado en ese momento. Ahí no hay que interpretar nada: se sigue cada sesión en orden y se compara con el flujo declarado.

Hay tres sesiones. Una hace el recorrido completo; otra pide el pago antes de definir el envío y el servidor la devuelve al paso que falta, que es el comportamiento correcto; la tercera es el hallazgo.

Una condición de carrera aparece cuando el servidor primero lee un dato («el vale tiene 20.000 de saldo»), luego decide, y por último escribe el cambio («descontar 20.000»), con un hueco entre la lectura y la escritura. Si dos solicitudes llegan dentro de ese hueco, las dos leen el mismo saldo, las dos deciden que se puede, y las dos descuentan. En el catálogo de debilidades es la CWE-362, «Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition)», y en la guía de OWASP se toca en las pruebas de tiempos de proceso y de veces que se puede usar una función (WSTG-BUSL-04 y WSTG-BUSL-05).

En un informe esto se demuestra leyendo el registro del servidor, que muestra los instantes y los saldos leídos por cada solicitud, y no hace falta lanzar ráfagas de peticiones contra un sistema para entender el mecanismo. La corrección es hacer la comprobación y la actualización como una sola operación indivisible: una transacción con bloqueo, una actualización condicionada al saldo o una restricción única en la base de datos.

Abre el laboratorio y mira la tabla de canjes. Un vale se canjea una vez: la solicitud siguiente debería leer saldo cero y ser rechazada. Eso es lo que ocurre en un vale. En el otro, varias solicitudes leyeron el mismo saldo de partida con apenas milisegundos de diferencia, y todas se aprobaron.

La columna «ms» y la columna «saldo_leido» son las dos pistas: si tres canjes leen el mismo saldo antes de que el primero lo descuente, el control comprueba y descuenta en dos tiempos.

El impacto de la carrera se cuantifica con el propio registro: lo que se aprobó en total menos lo que el vale tenía derecho a conceder una sola vez. Es un cálculo con los datos de la tabla, y es el número que un responsable de negocio entiende sin conocimientos técnicos.

Al redactar el hallazgo se separa lo observado de lo extrapolado. Esto es lo observado en una prueba con un vale del equipo; el cliente decide si estima la exposición real, y para eso necesita la cifra de esta evidencia, no una proyección mayor.