Laboratorio: Multi-endpoint race conditions
PreviousLaboratorio: Bypassing rate limits via race conditionsNextLaboratorio: Single-Endpoint Race Conditions
Last updated
Last updated
Lo que pasa en este punto es que se puede validar la posible condición de carrera de el endpoint POST /cart/checkout debido a su tiempo de validación solo de 600 ms, entonces lo que se hará será tomarlo en un ataque parallel single connection junto con la petición de añadir una jacket DOS VECES ESA PETICIÓN, ¿por qué? basicamente porque queremos lograr la sincronización de la peticiones aprovechandonos de la condición de carrera haciendo que cuando compre una gift card la interpreté la race condition con la compra de la jacket sin validar el precio con el credit store de $100 que tenía en la aplicación.
Y me devuelve 200 OK:
Si el calentamiento de la conexión no hace ninguna diferencia, hay varias soluciones a este problema.
Usando Turbo Intruder, puede introducir un breve retraso en el lado del cliente. Sin embargo, como esto implica dividir sus solicitudes de ataque reales a través de varios paquetes TCP, usted no será capaz de utilizar la técnica de ataque de un solo paquete. Como resultado, en objetivos de alto jrúd, es poco probable que el ataque funcione de manera confiable independientemente del retraso que establezcas.
