Contournement d’une limitation via Race condition

Multi-endpoint race conditions

Lab: Multi-endpoint race conditions | Web Security AcademyWebSecAcademy

Contexte du lab

Le processus d’achat du site comporte une condition de course entre plusieurs endpoints. En exploitant le timing entre les requêtes, on peut faire valider un achat à un prix non prévu (ou avec un état de panier incohérent). Objectif : acheter la Lightweight L33t Leather Jacket alors que, normalement, le serveur bloque avec : “Not enough store credit for this purchase”.

Identifiants : wiener:peter

1) Obtenir du crédit via une gift card

On a la possibilité d’acheter une gift card de 10$.

1. Acheter la gift card.

2. Valider la carte : le site fournit un code, par exemple : vataqFjyFB

Entrer le code dans le champ prévu → le store credit augmente.

2) Comprendre la protection côté serveur

Quand on essaie d’acheter la veste sans assez de crédit, le serveur renvoie :

Not enough store credit for this purchase

Donc il existe une validation serveur qui vérifie si le crédit est suffisant au moment du checkout.

3) Idée de l’attaque : course entre “add to cart” et “checkout”

On va exploiter une désynchronisation :

La requête checkout est plus rapide (ex : ~40 ms)

La requête add-to-cart de la veste est plus lente (ex : ~342 ms)

Si on envoie les requêtes de façon à ce que le checkout soit traité avant la mise à jour réelle du panier, le serveur peut :

• vérifier un état “favorable” (panier ≠ veste, ou prix/total pas encore recalculé),

• puis finaliser l’achat alors que l’état réel du panier change juste après.

4) Mise en place dans Burp (logique générale)

A. Préparer les requêtes

Créer un groupe contenant :

1. Add to cart (pour la veste)

2. Checkout (validation/achat)

L’objectif est de les envoyer en parallèle mais dans la même connexion TCP (pour maximiser la collision de timing et la cohérence de session).

B. Exécution

• Envoyer add-to-cart et checkout “en même temps”.

• Comme add-to-cart est plus lent, le checkout peut passer la validation avant que l’ajout de la veste ne soit entièrement pris en compte côté serveur.

5) Détail important : ajouter une requête “GET /” en plus

Pour que l’exploit fonctionne de manière fiable, il faut ajouter une requête supplémentaire dans le groupe :

• GET / (requête vers la racine)