Empilement de coupons

Qu'est-ce que l'empilement de coupons#

Le stacking de coupons est une vulnérabilité de logique métier dans laquelle un coupon à usage unique, un bonus de parrainage ou un crédit promotionnel est utilisé plus de fois que l'application ne le prévoit. L'instance canonique est une race condition Time-Of-Check / Time-Of-Use (TOCTOU) sur un endpoint /apply-coupon, mais le même résultat business peut être atteint via la réutilisation séquentielle d'un code, le replay cross-account, ou en empilant des types de promotions incompatibles dans une seule commande. La classe de vulnérabilité est mappée à CWE-841 (Improper Enforcement of Behavioral Workflow) et à OWASP A04:2021 — Insecure Design, parce que le défaut n'est pas un filtre d'input manquant mais un contrôle de concurrence ou de policy manquant sur une transition d'état.

Le score de base CVSS v3.1 est de 6.5 (Medium) avec le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. La confidentialité et la disponibilité ne sont pas affectées, mais l'intégrité est élevée car le prix, le total de la commande et les ledgers de revenus sont directement corrompus par l'attaquant. En pratique, l'impact business dépasse fréquemment la note CVSS : un seul attaquant lançant Burp Suite Turbo Intruder peut vider un budget promotionnel à six chiffres en quelques secondes, et la perte évolue linéairement avec l'automatisation plutôt qu'avec la compétence de l'attaquant.

Il est important de distinguer le stacking de coupons de la manipulation de prix générique. La manipulation de prix modifie un total fourni par le client ({"price": -10}) et se corrige en recomputant le total côté serveur. Le stacking de coupons, en revanche, envoie le bon code de coupon vers le bon endpoint avec la bonne identité utilisateur — le serveur échoue simplement à imposer qu'un code égale une redemption lorsque N requêtes concurrentes entrent en collision. Les deux coexistent souvent, mais les contrôles diffèrent : la recomputation côté serveur ne protège pas contre une race condition sur la table des coupons elle-même.

Mécanisme#

Le flow vulnérable contient une fenêtre mesurable entre la lecture de l'état du coupon et son écriture. Pendant cette fenêtre, des requêtes parallèles observent toutes used = false, toutes procèdent, et toutes commitent une redemption.

L'exploitation se réduit à quatre étapes ordonnées que tout testeur peut reproduire :

1. Identifier une surface de remise — champ coupon, lien de parrainage, redemption de fidélité, application de carte cadeau.
2. Capturer une requête POST /apply-coupon valide dans un proxy et la rejouer une fois dans Repeater pour confirmer le comportement de référence.
3. Envoyer 20 à 50 copies de la même requête via une attaque HTTP/2 single-packet afin que tous les bytes arrivent dans un seul segment TCP.
4. Inspecter l'ensemble des réponses : plusieurs 200 OK pour un code à usage unique, une somme de remises dépassant le total du panier, ou un discount_id dupliqué dans les line items de la commande confirme la race.

Une requête d'exploitation représentative ressemble à ceci :

POST /checkout/apply-promo HTTP/2
Host: shop.example.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
 
{"promo_code": "FIRST50", "order_id": "ord_88abc"}

Vingt copies de cette requête, gated sur le dernier byte et libérées simultanément, appliqueront FIRST50 vingt fois sur un serveur vulnérable. La fenêtre de race est typiquement de 1 à 50 millisecondes sur une application derrière un CDN et considérablement plus large sur un backend monolithique sous charge.

Variantes d'attaque#

La race TOCTOU est le cas canonique, mais le même résultat financier est atteignable par plusieurs chemins non concurrents que les défenseurs manquent souvent.

Les variantes cross-account et parrainage sont particulièrement difficiles à détecter car chaque requête individuelle est bien formée et authentifiée comme un utilisateur légitime différent. La détection ici nécessite une analyse au niveau du graphe (détection de cycles dans le graphe de parrainage, corrélation par device-fingerprint entre comptes) plutôt qu'une validation par requête.

Exemples concrets#

Instacart — HackerOne #157996#

Le chercheur Jack Cable (@cablej) a rapporté en 2016 que l'endpoint de redemption de coupons d'Instacart permettait au même code promo d'être utilisé deux fois via des requêtes concurrentes. Le backend vérifiait le statut de redemption puis appliquait le crédit, mais l'update n'était pas atomique. Instacart a accordé une bounty de $200. Après le patch initial, Cable a trouvé un bypass qui utilisait deux codes différents simultanément, stackant toujours les économies — un rappel que corriger la requête de surface sans corriger le modèle transactionnel sous-jacent laisse la classe de bug intacte.

Stripe — HackerOne #1849626#

En janvier 2023, le chercheur @ian a découvert que l'endpoint d'acceptation de fee discount de Stripe était vulnérable à une race condition. En appelant l'endpoint d'acceptation de remise 30 fois en parallèle via Burp Suite Turbo Intruder, il a accumulé $600 000 de volume de transaction sans frais à partir d'une offre promotionnelle unique de $20 000. La perte de Stripe par abus — environ $600 (3 pour cent de $20K) — était bien plus petite que le chiffre médiatique, mais le rapport illustre comment quelques secondes d'automatisation peuvent multiplier une promotion finie par 30x. Stripe a payé $5 000 et a résolu le problème avec une idempotence côté serveur sur l'appel d'acceptation de la remise.

Stripe — HackerOne #1717650#

Un rapport Stripe distinct de septembre 2022 a montré que les codes promotionnels portant des limites de redemption explicites (par exemple limit=1) pouvaient être utilisés au-delà de leur plafond via une race condition sur les liens Stripe Checkout. L'exploitation ne nécessitait aucun outillage particulier — seulement un navigateur ouvrant le même lien checkout dans plusieurs onglets simultanément. Stripe a payé $250 et a corrigé le problème avec un suivi atomique de la redemption. La bounty plus faible par rapport à #1849626 reflète la perte directe plus petite, mais la cause racine et la classe sont identiques.

WooCommerce Smart Coupons — CVE-2020-36841#

Tous les incidents de stacking de coupons ne sont pas des race conditions. CVE-2020-36841 dans WooCommerce Smart Coupons (versions ≤4.6.0) permettait à des utilisateurs non authentifiés de s'envoyer des chèques cadeaux d'une valeur arbitraire en abusant d'un bypass d'autorisation dans la logique de création de coupons. L'impact financier est fonctionnellement équivalent à une attaque de stacking réussie — les attaquants fabriquaient de la valeur de remise à partir de rien — mais la cause racine est un contrôle d'accès manquant sur l'endpoint de création plutôt qu'une fenêtre TOCTOU. Patché en version 4.6.5. L'avis est tracké sous GHSA-x279-24jv-7gr3.

Détection#

Test manuel#

Le test manuel pour le stacking de coupons est rapide une fois les surfaces de remise cartographiées. La procédure est identique pour les coupons, parrainages, cartes cadeaux et redemptions de fidélité.

1. Capturer une requête POST /apply-coupon valide dans Burp Proxy.
2. La rejouer trois à cinq fois dans Repeater. Si le même code à usage unique s'applique au second envoi, vous avez une réutilisation de code hors race — pas besoin d'outillage supplémentaire.
3. Envoyer la requête dans Burp Suite Turbo Intruder et utiliser le template PortSwigger race-single-packet-attack.py. Configurer 20 requêtes parallèles gated sur le même mot. Ouvrir la gate ; les vingt bytes partent ensemble sur une seule connexion HTTP/2.
4. Après le batch, lire le total du panier, le solde de crédit du compte, et la colonne current_uses du coupon. Plusieurs réponses 200 OK, une somme de remises supérieure au panier, ou current_uses inférieur au nombre de requêtes confirment tous la race.
5. Répéter l'exercice avec des inputs mutés : quantity: -1, discount_percent: 150, deux codes valides différents en parallèle, le même code depuis deux comptes sur le même device.

Le template Turbo Intruder qui pilote l'exploitation est court :

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2)
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')
 
def handleResponse(req, interesting):
    table.add(req)

Détection automatisée#

La détection programmatique se concentre sur les signaux fiables à travers les stacks : distribution des réponses, divergence d'effets de bord, et invariants de base de données.

Les outils open-source qui automatisent cette surface incluent l'extension Burp Race the Web, Turbo Intruder avec le template single-packet, ffuf avec une concurrence élevée (-t 30) pour le probing séquentiel, et des scripts Python custom asyncio plus httpx pour un timing précis. Caido offre une capacité similaire de replay-group pour les équipes ayant migré au-delà de Burp.

BreachVex détecte le stacking de coupons via un probing dédié de race condition sur les endpoints de coupons, promo, parrainage et carte cadeau découverts pendant la cartographie de la surface d'attaque. Le scanner rejoue chaque requête candidate en parallèle, compare la distribution des réponses à une baseline single-shot, et émet un finding CONFIRMED uniquement lorsque la divergence d'effet de bord (multiples redemptions réussies, max_uses dépassé, ou line items de remise dupliqués) est observée, chaque finding confirmé étant adossé à un flux de preuve dual-judge.

Prévention#

Les deux contrôles ci-dessous fonctionnent ensemble. La transaction atomique empêche la race sur la ligne du coupon elle-même, et la clé d'idempotence empêche que la même opération logique soit tentée deux fois sous toute autre forme.

Transactions atomiques en base#

Le pattern vulnérable lit l'état du coupon hors d'un verrou et l'écrit plus tard :

# VULNERABLE — TOCTOU window between check and update
async def apply_coupon(order_id: str, code: str, user_id: str) -> dict:
    coupon = await db.fetch_one("SELECT * FROM coupons WHERE code=:code AND used=false", {"code": code})
    if not coupon:
        raise ValueError("Invalid coupon")
    # ...network round-trip, ORM overhead, no lock held...
    await db.execute("UPDATE coupons SET used=true WHERE id=:id", {"id": coupon.id})
    await db.execute("INSERT INTO redemptions (coupon_id, user_id, order_id) VALUES (:c, :u, :o)",
                     {"c": coupon.id, "u": user_id, "o": order_id})
    return {"discount": float(coupon.discount_amount)}

Le pattern corrigé enrobe la lecture et l'écriture dans une seule transaction avec un verrou au niveau de la ligne, afin que les transactions concurrentes bloquent sur SELECT ... FOR UPDATE au lieu de la dépasser en course :

# FIXED — SELECT FOR UPDATE holds a row lock for the duration of the tx
from sqlalchemy import text
 
async def apply_coupon(order_id: str, code: str, user_id: str) -> dict:
    async with get_db() as db:
        async with db.begin():
            coupon = await db.execute(text("""
                SELECT id, discount_amount, max_uses, current_uses
                FROM coupons
                WHERE code = :code
                  AND is_active = true
                  AND (expires_at IS NULL OR expires_at > now())
                FOR UPDATE NOWAIT
            """), {"code": code}).fetchone()
 
            if not coupon:
                raise ValueError("Coupon not found or expired")
            if coupon.current_uses >= coupon.max_uses:
                raise ValueError("Coupon exhausted")
 
            existing = await db.execute(text(
                "SELECT 1 FROM coupon_redemptions WHERE coupon_id=:cid AND user_id=:uid"
            ), {"cid": coupon.id, "uid": user_id}).fetchone()
            if existing:
                raise ValueError("Already redeemed by this user")
 
            await db.execute(text(
                "UPDATE coupons SET current_uses = current_uses + 1 WHERE id = :cid"
            ), {"cid": coupon.id})
            await db.execute(text("""
                INSERT INTO coupon_redemptions (coupon_id, user_id, order_id)
                VALUES (:cid, :uid, :oid)
            """), {"cid": coupon.id, "uid": user_id, "oid": order_id})
 
            return {"discount_amount": float(coupon.discount_amount)}

Une contrainte UNIQUE(coupon_id, user_id) sur coupon_redemptions fournit un filet de sécurité imposé par la base : même si un bug de concurrence passe le code applicatif, le second INSERT échoue avec une violation de contrainte plutôt que de double-rédemmer silencieusement.

Clés d'idempotence#

Pour les flows à plus forte valeur — checkouts portant un paiement, acceptation de fee discount — couplez la transaction atomique à une clé d'idempotence côté serveur dérivée de l'opération, et non d'un header fourni par le client. L'exemple ci-dessous utilise SET NX Redis pour acquérir un lock court-vivant par (user, code, order) et une transaction Knex avec forUpdate pour effectuer la redemption atomiquement :

const Redis = require('ioredis');
const client = new Redis();
 
async function applyCoupon(req, res) {
  const { code, orderId } = req.body;
  const userId = req.user.id;
 
  // Idempotency key: one application per (user, code, order)
  const idemKey = `coupon:${userId}:${code}:${orderId}`;
  const acquired = await client.set(idemKey, '1', 'NX', 'EX', 300); // 5 min TTL
 
  if (!acquired) {
    return res.status(409).json({ error: 'Coupon application already in progress' });
  }
 
  try {
    const result = await db.transaction(async (trx) => {
      const coupon = await trx('coupons')
        .where({ code, is_active: true })
        .forUpdate()
        .first();
 
      if (!coupon || coupon.current_uses >= coupon.max_uses) {
        throw new Error('Coupon invalid or exhausted');
      }
 
      await trx('coupons').where({ id: coupon.id }).increment('current_uses', 1);
      await trx('coupon_redemptions').insert({
        coupon_id: coupon.id, user_id: userId, order_id: orderId,
      });
 
      return { discount: coupon.discount_amount };
    });
 
    return res.json(result);
  } finally {
    await client.del(idemKey);
  }
}

Deux contrôles supplémentaires complètent une implémentation défendable. Premièrement, recomputez le total de la commande côté serveur à chaque soumission de checkout et clampez le résultat avec max(final_price, 0) afin qu'aucune combinaison de remises ne puisse produire une charge négative. Deuxièmement, ne brûlez jamais les coupons dans un worker asynchrone — la fenêtre entre commit et burn est exactement le bug exploité dans les rapports Stripe et Instacart ci-dessus.

Sujets liés#

• Contournement de limite — Même pattern de race condition TOCTOU appliqué aux quotas par utilisateur.
• Contournement d'étape de workflow — Sauter le paiement après avoir appliqué des coupons cumulés.
• Abus d'arrondi monétaire — Cumul d'erreurs d'arrondi avec les maths de remise.
• Failles de logique métier (vue d'ensemble) — Page pilier couvrant les 6 variantes.

Ressources#

• Race Conditions — PortSwigger Web Security Academy
• Stripe Fee Discounts Race — HackerOne #1849626
• Instacart Coupon Race — HackerOne #157996
• OWASP A04:2021 — Insecure Design