Manipulation de prix

Qu'est-ce que la manipulation de prix#

La manipulation de prix est une vulnérabilité de logique métier dans laquelle une application accepte une valeur monétaire — price, unit_price, amount, total ou subtotal — directement depuis une requête client et l'utilise comme coût de référence d'une transaction. Comme la valeur est fournie par le client, un attaquant peut intercepter la requête dans un proxy, changer price=49900 en price=1 et finaliser l'achat à un centime. Le serveur ne re-valide jamais la valeur contre son propre catalogue produit. Cette vulnérabilité est cataloguée comme CWE-840 (Business Logic Errors) avec une faiblesse contributive CWE-20 (Improper Input Validation), et relève de OWASP A04:2021 — Insecure Design.

La vulnérabilité est invisible aux scanners d'injection traditionnels. Aucun payload ne provoque d'erreur 500. Aucune regex ne matche une chaîne malveillante. La requête est syntaxiquement et sémantiquement valide — elle contient simplement un nombre que le développeur n'a jamais voulu rendre modifiable. La détection nécessite de raisonner sur l'intention de chaque champ, raison pour laquelle les outils DAST et les WAF passent tous deux à côté. Les pentesters manuels et les scanners conscients de la logique métier la détectent en interceptant le flux de checkout et en modifiant les champs numériques un à un.

L'exposition financière est proportionnelle au volume de commandes. Une seule faille non détectée sur une plateforme e-commerce à fort trafic peut produire des pertes à six chiffres avant que la réconciliation ne révèle l'écart. C'est pourquoi le top des bounties HackerOne pour la logique métier place régulièrement la manipulation de prix dans les cinq sous-types les mieux récompensés, et pourquoi les divulgations en contexte Shopify ont historiquement rapporté 25 000 à 150 000 dollars selon que la faille touche un seul magasin ou le checkout au niveau plateforme.

Mécanisme#

L'exploitation repose sur une seule frontière de confiance brisée : le serveur délègue l'autorité de tarification au client. Le flux est identique à travers les stacks à formulaire caché, REST et GraphQL.

L'attaque se résume à quatre étapes déterministes :

1. L'utilisateur ajoute un article via l'interface normale ; le navigateur émet un POST qui inclut le prix affiché par la page.
2. Un proxy interceptant (Burp, Caido, mitmproxy) retient la requête et l'attaquant réécrit le champ price avec une valeur arbitraire.
3. Le serveur insère le line item du panier en utilisant le prix fourni comme unit_price, sans interroger son propre catalogue produit.
4. Le checkout somme les line items et facture le total résultant — déjà empoisonné par le nombre fourni par l'attaquant.

La requête vulnérable canonique, capturée contre une stack e-commerce réelle :

POST /api/cart/add HTTP/2
Host: shop.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...
Cookie: session=abc123
 
{
  "product_id": "jacket-heavyweight-001",
  "quantity": 1,
  "price": 1
}

Un backend vulnérable répond {"cart_id": "cart_xyz", "line_total": 1, "currency": "USD"} et facture un centime pour une veste à 499 $. L'en-tête Authorization est valide — l'attaquant est un client authentifié — ce qui explique précisément pourquoi les scanners qui notent les requêtes sur la sémantique HTTP ne voient rien d'anormal.

Variantes d'attaque#

Cinq techniques distinctes produisent le même résultat ; les contrôles défensifs doivent couvrir les cinq.

La variante quantité négative mérite une attention particulière. De nombreux backends vérifient price >= 0 mais ne vérifient jamais quantity >= 1, donc un attaquant garde un article à 1 000 $ avec une quantité -1 pendant qu'un autre article à bas coût porte la commande, et l'arithmétique produit un total négatif que le processeur de paiement interprète comme une obligation de remboursement. L'integer overflow est l'inverse : des valeurs positives qui mathématiquement basculent négatives, déjouant la validation naïve.

Exemples réels#

Les divulgations suivantes établissent que la manipulation de prix est un problème actuel, rémunéré, multi-plateformes — pas une préoccupation théorique.

HackerOne #218748 — Falsification de paramètres sur checkout XML e-commerce — Un attaquant a intercepté le payload XML de checkout, modifié l'élément <price> et finalisé des achats aux prix de son choix. Sévérité : Élevée. Bounty payé (montant non divulgué). Le rapport démontre que les stacks XML sont également exposées ; la classe de vulnérabilité est agnostique au transport.

HackerOne #364843 — Manipulation du prix total OLO via quantité négative — Sur la plateforme de commande de repas OLO, mettre quantity=-1 pour un article à forte valeur tout en gardant d'autres articles dans le panier amenait l'arithmétique backend à soustraire le coût de cet article du total de commande. Les attaquants pouvaient commander des repas gratuitement ou recevoir un crédit net. Le correctif a nécessité de valider quantity >= 1 à la frontière API, pas seulement à l'UI.

HackerOne #927661 — Plateforme de paiement, montant falsifiable par fraction négative — Un processeur de paiement acceptait un paramètre amount en fraction négative, réduisant le total dû. Bounty : 500 $ (Moyen, plafonné car l'exploitabilité était bornée à de petites réductions). Cela illustre que la sévérité varie directement avec l'ampleur de l'écart possible par rapport au prix légitime.

HackerOne #1562515 — Glovo integer overflow — Après que Glovo a remédié à un premier rapport de falsification de prix en supprimant le champ price, un suivi a démontré que le champ quantity restant était vulnérable à l'integer overflow : mettre quantity à 9223372036854775807 (INT64_MAX) faisait basculer le total ligne en négatif. La leçon est que retirer un champ est insuffisant quand l'arithmétique dépend encore de valeurs client.

HackerOne #1446090 — Krisp, downgrade de sièges sans revalidation — Un endpoint PUT /subscription acceptait un nombre de seats inférieur au nombre déjà provisionné sans re-valider contre le palier de facturation. Les clients pouvaient downgrader leur facturation tout en conservant l'accès à tous les sièges provisionnés — une manipulation de prix exprimée via l'état d'abonnement plutôt que via un panier.

CVE-2025-56426 — Manipulation de prix panier sur Bagisto CMS — Bagisto, plateforme e-commerce open-source basée sur Laravel, acceptait un paramètre price dans son API d'ajout au panier sans recherche catalogue côté serveur. Noté CVSS 8.1 Élevé avec le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H. Patché dans Bagisto 2.2.3 en avril 2025. Le code pré-patch est un exemple d'école : le contrôleur passait request()->price directement au constructeur de la ligne panier.

PortSwigger Web Security Academy publie trois labs de référence qui reproduisent ces patterns : Excessive trust in client-side controls (modifier price pour la veste en cuir), Low-level logic flaw (integer overflow 32 bits sur les totaux ligne) et Infinite money logic flaw (discount stacking de carte cadeau). Les labs sont utiles pour former les pentesters car l'exploitation est identique aux cas en production ci-dessus.

Détection#

Test manuel#

Burp Suite (ou Caido) est l'outil standard. La méthodologie est procédurale et reproductible :

1. Configurer le proxy pour intercepter toutes les requêtes ; se connecter à la cible comme client normal.
2. Ajouter un produit au panier via le flux UI légitime.
3. Dans le POST /cart/add intercepté (ou équivalent), chercher dans le corps de la requête tout champ numérique dont la valeur correspond au prix affiché — noms courants : price, unit_price, amount, cost, total, subtotal, unitPrice.
4. Inspecter les inputs cachés de formulaire dans le HTML de réponse : document.querySelectorAll('input[type=hidden]') depuis la console navigateur capture les patterns legacy.
5. Modifier le champ candidat à 1, puis 0.01, puis -9999, en envoyant chaque variante via Burp Repeater. Toujours tester une valeur qui diffère exactement de 1 (4989 vs 4990) — les changements subtils passent la validation de format tout en prouvant le problème de confiance.
6. Compléter le flux de checkout. Capturer trois artefacts : la page produit originale, la requête interceptée modifiée et la confirmation de commande montrant que le prix falsifié a été facturé. C'est suffisant comme preuve pour un proof tier CVSS confirmed — changement d'état financier vérifié.

Répéter la procédure pour l'endpoint checkout lui-même. Certaines applications valident correctement les prix sur /cart/add mais acceptent un cart_total fourni par le client sur /checkout/confirm, sautant la re-sommation des line items. Les deux surfaces doivent être testées indépendamment.

Détection automatisée#

Les scanners DAST génériques (ZAP, Burp Active Scan, Acunetix) passent à côté de cette classe car aucun payload ne déclenche d'erreur. La détection spécialisée en logique métier nécessite :

• Comparer les champs du corps de requête aux prix affichés sur la page source (corrélation DOM-vers-API).
• Envoyer des variantes à prix modifié et asserter que le total de commande dans la réponse est égal à la valeur modifiée.
• Heuristiques sur les noms de champs matchant ^(unit_)?price|amount|cost|total|subtotal$ suivies d'une mutation automatisée et d'un diff de réponse.

Limites : les scanners qui n'ont pas de gestion de session authentifiée ne peuvent pas atteindre l'endpoint panier. Les scanners qui n'ont pas de crawl stateful ne peuvent pas corréler le prix affiché avec le champ de corps de requête. Des faux positifs apparaissent sur des endpoints légitimes de tarification dynamique (remises bundle, tarification contractuelle B2B) où price est un input valide d'un appelant privilégié.

BreachVex détecte cela via son moteur de logique métier, qui crawle les flux panier et checkout avec une session authentifiée, identifie les champs numériques dont les valeurs correspondent aux prix catalogue, et asserte l'intégrité en soumettant des variantes falsifiées et en vérifiant que le total de commande suit l'input modifié plutôt que la valeur catalogue.

Prévention#

Recherche catalogue côté serveur#

Le correctif canonique tient en une règle : ne jamais lire le prix depuis la requête. Toujours le rechercher par product_id depuis le catalogue de référence. Ci-dessous une comparaison côte à côte en FastAPI ; l'équivalent Express est identique en forme.

Python vulnérable (FastAPI) :

from fastapi import APIRouter, Depends, HTTPException
from pydantic import BaseModel, Field
 
router = APIRouter()
 
class CartItem(BaseModel):
    product_id: str
    quantity: int
    price: float  # BUG: writeable from client
 
@router.post("/cart/add")
async def add_to_cart(item: CartItem, db=Depends(get_db)):
    cart_entry = CartEntry(
        product_id=item.product_id,
        quantity=item.quantity,
        unit_price=item.price,  # <-- attacker-controlled
    )
    db.add(cart_entry)
    db.commit()
    return {"line_total": item.quantity * item.price}

Python corrigé (FastAPI) :

from fastapi import APIRouter, Depends, HTTPException
from pydantic import BaseModel, Field
 
router = APIRouter()
 
class CartAddRequest(BaseModel):
    product_id: str
    quantity: int = Field(ge=1, le=100)
    # price field deliberately omitted
 
@router.post("/cart/add")
async def add_to_cart(item: CartAddRequest, db=Depends(get_db)):
    product = db.query(Product).filter(Product.id == item.product_id).first()
    if not product:
        raise HTTPException(status_code=404, detail="Product not found")
 
    cart_entry = CartEntry(
        product_id=item.product_id,
        quantity=item.quantity,
        unit_price=product.price,  # <-- authoritative catalog price
    )
    db.add(cart_entry)
    db.commit()
    return {"line_total": item.quantity * product.price}

Deux détails structurels comptent au-delà de la recherche catalogue. D'abord, CartAddRequest ne déclare pas de champ price — Pydantic rejettera les champs supplémentaires si model_config = ConfigDict(extra='forbid') est défini, éliminant les surprises de mass-assignment des sérialiseurs ORM. Ensuite, quantity est borné par Field(ge=1, le=100) pour bloquer les valeurs négatives et les tentatives d'integer overflow à la frontière API, avant toute arithmétique.

Re-validation au checkout et tokens panier signés#

Une seconde couche de contrôle protège contre les failles de logique ailleurs dans le pipeline panier. Même si chaque requête add était correctement tarifée, recalculer le total de commande au checkout depuis le catalogue — ne jamais faire confiance aux unit prices stockés de la table panier et ne jamais accepter un cart_total fourni par le client.

@router.post("/checkout/confirm")
async def confirm_order(order_id: str, db=Depends(get_db)):
    cart_items = db.query(CartEntry).filter(
        CartEntry.order_id == order_id
    ).all()
    calculated_total = sum(
        db.query(Product).get(item.product_id).price * item.quantity
        for item in cart_items
    )
    # Always recompute; never trust submitted totals
    charge_payment(amount=calculated_total)

Pour les architectures stateless où le panier vit côté client ou dans un cache CDN edge, générer un HMAC côté serveur du contenu du panier au moment où les prix sont résolus, et re-vérifier la signature au checkout :

import hmac, hashlib, json, os
 
SECRET = os.environ["CART_SIGNING_KEY"]
 
def sign_cart(cart: dict) -> str:
    payload = json.dumps(cart, sort_keys=True)
    return hmac.new(
        SECRET.encode(), payload.encode(), hashlib.sha256
    ).hexdigest()
 
def verify_cart(cart: dict, signature: str) -> bool:
    return hmac.compare_digest(sign_cart(cart), signature)

Toute modification des quantités, prix ou IDs de produits invalide la signature, et l'endpoint checkout refuse la commande. La clé de signature doit tourner indépendamment des secrets de session et résider dans un gestionnaire de secrets — jamais dans le contrôle de version.

Sujets liés#

• Abus de quantité négative — Inversion arithmétique via qty=-1 ou integer overflow.
• Empilement de coupons — Race conditions TOCTOU sur l'utilisation de coupons.
• Abus d'arrondi monétaire — Imprécision float + champs de calcul contrôlés client.
• Failles de logique métier (vue d'ensemble) — Page pilier couvrant les 6 variantes.

Ressources#

• PortSwigger : Excessive trust in client-side controls (lab)
• OWASP : Web Parameter Tampering
• HackerOne #1562515 : Glovo integer overflow vulnerability
• CWE-840 : Business Logic Errors