Condición de carrera (Race Condition)

Una condición de carrera es un fallo de temporización. Aparece cuando una aplicación asume que las operaciones ocurren una tras otra, pero un atacante las fuerza a ocurrir al mismo tiempo. La forma clásica es una brecha time-of-check to time-of-use (TOCTOU): la aplicación comprueba una condición (¿tiene saldo este cupón?) y luego actúa sobre ella (aplica el crédito), y el atacante introduce acciones adicionales en la ventana entre ambas.

Por qué importa

Las condiciones de carrera son peligrosas precisamente porque cada petición individual es legítima, así que evaden las herramientas centradas en la entrada igual que lo hacen las vulnerabilidades de lógica de negocio. Además, no son deterministas: el mismo código puede comportarse correctamente miles de veces y fallar de forma catastrófica cuando la temporización se alinea, lo que significa que las pruebas secuenciales tradicionales casi nunca las activan. Esa combinación, alto impacto y baja detectabilidad, las convierte en algunos de los hallazgos más rentables del bug bounty y de las pruebas de seguridad de API.

Cómo funciona una condición de carrera

Imagina un cupón que vale para un solo uso. Normalmente el flujo es:

1. Llega la petición; el servidor comprueba que el cupón no se ha usado.
2. El servidor aplica el crédito y lo marca como usado.

Ahora un atacante envía 50 peticiones de canje exactamente en el mismo instante. Si las 50 llegan al paso 1 antes de que ninguna de ellas complete el paso 2, el servidor las valida todas contra el mismo estado "sin usar" y aplica el crédito 50 veces.

Comprobar condición

→ventana mínima

El atacante altera el estado

→

Usar resultado obsoleto

La lógica era correcta para una petición a la vez, pero se rompió bajo concurrencia. Esa brecha, entre la comprobación y el uso, es donde vive el ataque.

Dónde aparecen las condiciones de carrera

Cómo probarlas

Encuentra acciones de un solo uso o limitadas y luego dispara muchas peticiones idénticas tan cerca de la simultaneidad como sea posible. Burp Suite Repeater puede enviar un grupo de peticiones en paralelo, y un breve script de Python que use peticiones asíncronas puede hacer lo mismo.

Cómo prevenirlas

Defenderse de las condiciones de carrera significa eliminar la suposición de un orden de ejecución seguro:

• Bloqueo: mutexes, semáforos o bloqueos de fila de base de datos para que solo una operación toque el recurso a la vez.
• Operaciones atómicas: combinar la comprobación y la acción en un único paso indivisible.
• Claves de idempotencia: garantizar que una petición repetida solo surta efecto una vez.
• Restricciones de base de datos: unicidad, bloqueo optimista (números de versión) o SELECT ... FOR UPDATE.

Las condiciones de carrera recompensan a los cazadores que entienden una aplicación lo bastante a fondo como para saber qué acciones se supone que deben ocurrir una sola vez, y luego demuestran que, bajo presión, ocurren más.