Contournement d'étape de workflow

Qu'est-ce que le contournement d'étape de workflow#

Un contournement d'étape de workflow est une vulnérabilité de logique métier dans laquelle un processus multi-étapes — combinant autorisation, paiement, vérification d'identité ou revue de conformité — est court-circuité en envoyant directement la requête de l'étape finale sans compléter les prérequis. Il est catalogué comme CWE-841 (Improper Enforcement of Behavioral Workflow) et constitue le focus de WSTG-BUSL-06 dans le OWASP Web Security Testing Guide. Il apparaît également dans OWASP A04:2021 — Insecure Design (renommée A06:2025 — Insecure Design dans la mise à jour OWASP Top 10:2025) et comme entrée dédiée Workflow Order Bypass dans le OWASP Top 10 for Business Logic Abuse 2025.

La caractéristique déterminante est un décalage entre l'expérience côté client et le modèle d'application côté serveur. Les développeurs construisent une UI linéaire propre — un assistant de checkout avec boutons "Suivant" désactivés, une page KYC qui cache "Approuver" tant que les documents ne sont pas téléversés — et supposent que l'utilisateur ne peut pas atteindre l'étape N sans compléter l'étape N-1. L'erreur est que les endpoints API derrière ces étapes UI sont accessibles indépendamment. Un attaquant utilisant Burp Suite ou curl peut appeler directement POST /api/v1/checkout/complete et — si le serveur n'interroge pas la colonne d'état du workflow en base avant de traiter la requête — la commande est créée sans paiement.

La distinction entre application front-end et application back-end constitue toute la vulnérabilité. La logique front-end guide les utilisateurs sur le chemin heureux ; la logique back-end est la seule chose qui protège les invariants métier. Chaque étape ayant une signification financière, sécuritaire ou de conformité doit être modélisée comme une transition d'état server-side que les étapes ultérieures vérifient explicitement. Tout ce qui est moindre est décoratif.

Mécanisme#

Un workflow multi-étapes est fondamentalement une machine à états finis (FSM) sur une transaction ou une session. Le serveur doit suivre l'état dans lequel se trouve chaque transaction (CART, ADDRESS, PAYMENT_PENDING, PAYMENT_CONFIRMED, COMPLETE) et rejeter toute requête tentant une transition non autorisée depuis l'état courant. Lorsque cette vérification est manquante ou partielle, n'importe quel endpoint ultérieur devient atteignable depuis l'état initial.

L'étape critique sautable varie selon le domaine. Le tableau ci-dessous liste les formes courantes de workflow où ce pattern récurre :

Une requête d'attaque canonique :

POST /api/v1/checkout/complete HTTP/1.1
Host: api.shop.example.com
Authorization: Bearer <user_jwt>
Content-Type: application/json
 
{"cart_id": "abc123", "shipping_address_id": "addr_456"}

Si le serveur retourne {"order_id": "ORD-789", "status": "confirmed"} sans appel préalable à /api/v1/checkout/payment, le paiement a été contourné. L'attaquant n'a injecté aucun payload — il a simplement appelé le dernier endpoint en premier.

Variantes d'attaque#

La variante CWOB — Checkout Without Borders dans le vocabulaire post-Kettle — défait le pattern défensif le plus courant : un handler séquentiel check-then-act. La recherche PortSwigger d'août 2023 de James Kettle, "Smashing the State Machine", a montré que chaque requête HTTP fait transiter une application à travers des sous-états internes dans des fenêtres ~1ms, et que l'attaque single-packet HTTP/2 — regroupant 30 requêtes dans la dernière frame d'une connexion HTTP/2 via Burp Turbo Intruder ou h2spacex — les synchronise dans une fenêtre d'exécution sub-1ms depuis un hôte distant. Cela transforme les race conditions distantes en races locales, rendant l'exploitation des sous-états viable contre toute FSM exposée à internet sans transitions atomiques.

Exemples du monde réel#

La classe de vulnérabilité est exploitée de manière constante aux niveaux de sévérité les plus élevés dans les bases CVE et les plateformes de bug bounty.

CVE-2025-14971 — Link Invoice Payment for WooCommerce (CVSS 5.3, 30 jan 2026). Les fonctions REST API createPartialPayment et cancelPartialPayment dans les versions ≤ 2.8.0 n'effectuent aucun contrôle de capacité ; un attaquant non authentifié peut créer des paiements partiels frauduleux ou annuler des paiements légitimes sur n'importe quelle commande en énumérant les IDs (CWE-862).

HackerOne #682617 — Starbucks Suisse (divulgué). Le chercheur a fabriqué un message de succès de paiement falsifié vers l'endpoint de callback de paiement card.starbucks.ch, créditant une carte Starbucks suisse sans transaction réelle — falsification de callback de paiement en production.

HackerOne #423546 — Shopify Wholesale (H1-514 Live Hacking Event). Le canal Wholesale permet aux boutiques de désactiver le checkout pour que les bons de commande nécessitent une revue par le staff. Le chercheur a trompé le routeur de checkout pour compléter un checkout normal (non revu) même avec checkout explicitement désactivé, contournant l'étape de revue obligatoire par le staff.

HackerOne #953083 — Shopify Theme Store (bounty 2 000 $). L'attaquant a publié un thème tiers payant sur sa boutique sans l'acheter en envoyant un XHR ThemePublishLegacy pendant qu'une installation de thème était en cours. Le workflow d'installation (add-to-cart → paiement → licence → install → publish) a été contourné en sautant à publish pendant la fenêtre d'installation — une race sur sous-état du monde réel.

HackerOne #1328278 — Stripe (divulgué). Les utilisateurs pouvaient acheter un produit à un prix archivé (désactivé) via un lien de paiement précédemment généré. Le traitement des liens par Stripe ne validait pas que le lien et le prix étaient tous deux actifs au moment du checkout.

HackerOne #1420697 — lemlist (divulgué). Une mauvaise gestion du moyen de paiement sur app.lemlist.com permettait à un attaquant d'activer un plan payant sans compléter de transaction. L'endpoint d'activation ne vérifiait jamais la confirmation du provider de paiement.

HackerOne #2012443 — Nord Security / NordVPN (divulgué). Une faille dans le service backend vérifiant le statut d'abonnement actif pouvait être contournée, accordant l'accès VPN à des utilisateurs sans abonnement valide (scope session).

HackerOne #2170559 — Cloudflare R2 (18 sept 2023, divulgué). Des contrôles d'accès insuffisants permettaient à un utilisateur d'activer le stockage objet R2 sans moyen de paiement enregistré — le prérequis "moyen de paiement valide" du workflow d'activation n'était pas appliqué côté serveur.

Détection#

Tests manuels#

La méthodologie Burp Repeater suit un protocole de test CWOB en cinq étapes tiré du lab Insufficient Workflow Validation de PortSwigger et de la recherche post-CWOB :

1. Cartographier le workflow. Parcourir une fois le flow légitime avec Burp en enregistrement. Construire une carte d'étapes listant chaque URL, méthode et identifiant unique.
2. Identifier l'étape monétaire. L'endpoint qui complète l'action financièrement significative (/checkout/complete, /subscription/activate, /kyc/approve).
3. Test de saut direct. Ouvrir une session navigateur fraîche et rejouer uniquement la requête de l'étape monétaire avec l'ID capturé. HTTP 200 avec un corps significatif = vérification de prérequis manquante.
4. Manipulation de paramètre. Chercher step, stage, status, payment_status, verified, confirmed dans les corps de requête. Les forcer à un état ultérieur.
5. Test de race CWOB. Tirer l'étape N-1 et l'étape N simultanément via Send group in parallel de Burp Repeater ou l'attaque single-packet HTTP/2 de Turbo Intruder. La librairie h2spacex basée sur Scapy effectue la synchronisation last-frame HTTP/2 pour un timing précis de race condition.

Pour les endpoints webhook, chercher dans les bundles JS et les docs OpenAPI des chemins comme /webhooks/stripe. Envoyer un corps JSON conçu mimant le format de succès du provider (par ex. {"type": "payment_intent.succeeded", "data": {"object": {"id": "pi_xxx"}}}) sans signature. Si l'application marque le paiement complet, la vérification HMAC est absente.

Détection automatisée#

Les scanners DAST traditionnels (Burp Active Scan, OWASP ZAP) ne peuvent pas détecter le contournement de workflow par conception — ils testent des requêtes individuelles sans comprendre les machines à états métier. Des outils dédiés ont émergé en 2025–2026 pour combler ce gap :

• Escape DAST exécute un moteur Business Logic Security Testing (BLST) feedback-driven qui modélise les workflows applicatifs et sonde les prérequis sautés.
• StackHawk a publié son moteur Business Logic Testing (BLT) en décembre 2025 ; Smart Crawl mappe les opérations OpenAPI en flows logiques et exécute des tests d'autorisation multi-utilisateurs sur ceux-ci.
• Pynt utilise des tests API logic-aware construits par-dessus les tests fonctionnels existants, opérant au niveau contextuel au-dessus du fuzzing d'inputs.
• Burp Turbo Intruder et h2spacex sont le standard de fait pour l'attaque single-packet CWOB.

BreachVex détecte cette classe via un sondage sequence-aware des endpoints multi-étapes combiné à la validation de signature webhook. Le scanner mappe les endpoints API découverts en clusters de workflow (checkout, abonnement, KYC, password reset, inscription), puis pour chaque cluster envoie la requête d'étape finale inférée dans une session authentifiée fraîche sans étapes préalables. Les findings sont marqués POTENTIAL_WORKFLOW_BYPASS quand l'endpoint final retourne HTTP 200 avec des mots-clés order/confirmation/activation ; ils sont promus CONFIRMED uniquement après qu'une vérification de comparaison d'état observe un changement d'état server-side. Les endpoints webhook sont sondés avec un payload de succès falsifié non signé ; si la réponse indique une mutation d'état, un finding séparé est émis avec une chaîne CWE-345 / CWE-841.

Prévention#

Application server-side d'une machine à états#

La seule défense durable est de modéliser chaque workflow multi-étapes comme une machine à états finis sur le serveur, avec l'état stocké en base (ou dans un magasin de session server-side) et jamais dérivé de paramètres fournis par le client. Chaque transition doit valider l'état courant avant de s'exécuter.

# VULNERABLE — no state check, server trusts that the front-end called payment first
@require_POST
def complete_order_vulnerable(request):
    checkout_id = request.POST["checkout_id"]
    checkout = Checkout.objects.get(id=checkout_id)
    order = create_order(checkout)  # No payment check, no state guard
    return JsonResponse({"order_id": order.id, "status": "confirmed"})
 
 
# FIXED — explicit FSM with current_step column in DB and transition table
class CheckoutState(models.TextChoices):
    CART = "cart"
    ADDRESS = "address"
    PAYMENT_PENDING = "payment_pending"
    PAYMENT_CONFIRMED = "payment_confirmed"
    COMPLETE = "complete"
    CANCELLED = "cancelled"
 
class Checkout(models.Model):
    id = models.UUIDField(primary_key=True)
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    current_step = models.CharField(
        max_length=32,
        choices=CheckoutState.choices,
        default=CheckoutState.CART,
    )
    payment_intent_id = models.CharField(max_length=64, null=True)
    payment_confirmed_at = models.DateTimeField(null=True)
 
ALLOWED_TRANSITIONS = {
    CheckoutState.CART: {CheckoutState.ADDRESS, CheckoutState.CANCELLED},
    CheckoutState.ADDRESS: {CheckoutState.PAYMENT_PENDING, CheckoutState.CANCELLED},
    CheckoutState.PAYMENT_PENDING: {CheckoutState.PAYMENT_CONFIRMED, CheckoutState.CANCELLED},
    CheckoutState.PAYMENT_CONFIRMED: {CheckoutState.COMPLETE, CheckoutState.CANCELLED},
}
 
@require_POST
def complete_order(request):
    checkout = get_object_or_404(
        Checkout, id=request.POST["checkout_id"], user=request.user
    )
    if checkout.current_step != CheckoutState.PAYMENT_CONFIRMED:
        return JsonResponse(
            {
                "error": "WORKFLOW_STATE_INVALID",
                "current_state": checkout.current_step,
                "required_state": CheckoutState.PAYMENT_CONFIRMED,
            },
            status=400,
        )
    order = create_order(checkout)
    checkout.current_step = CheckoutState.COMPLETE
    checkout.save()
    return JsonResponse({"order_id": order.id, "status": "confirmed"})

Vérification de signature HMAC sur webhook#

Ne jamais laisser le client signaler le succès du paiement. Utiliser des webhooks server-to-server avec vérification de signature cryptographique sur chaque événement avant toute mutation d'état.

# Stripe webhook signature verification (Python) — REQUIRED for every payment webhook
import os
import stripe
from flask import request
 
stripe.api_key = os.environ["STRIPE_SECRET_KEY"]
WEBHOOK_SECRET = os.environ["STRIPE_WEBHOOK_SECRET"]  # whsec_...
 
@app.route("/webhooks/stripe", methods=["POST"])
def stripe_webhook():
    payload = request.get_data()  # raw bytes — required for HMAC
    sig_header = request.headers.get("Stripe-Signature")
    try:
        event = stripe.Webhook.construct_event(
            payload, sig_header, WEBHOOK_SECRET
        )
    except (ValueError, stripe.error.SignatureVerificationError):
        # Reject unsigned or forged events — this is the bypass-prevention line
        return "", 400
 
    # Only after signature verification, mutate state
    if event["type"] == "payment_intent.succeeded":
        intent = event["data"]["object"]
        checkout = Checkout.objects.get(payment_intent_id=intent["id"])
        checkout.current_step = CheckoutState.PAYMENT_CONFIRMED
        checkout.payment_confirmed_at = timezone.now()
        checkout.save()
    return "", 200

L'équivalent Node.js utilise stripe.webhooks.constructEvent(rawBody, signature, secret) avec le corps brut de la requête. Parser le JSON d'abord puis le re-stringifier casse le HMAC car la représentation canonique en bytes est perdue — un bug silencieux courant.

Transitions d'état atomiques (anti-CWOB)#

Pour défaire l'attaque single-packet CWOB post-2023, chaque transition d'état doit être enveloppée dans une transaction base de données avec un verrou au niveau ligne acquis via SELECT FOR UPDATE. Cela sérialise les tentatives concurrentes de read-then-write sur la même ligne de workflow, éliminant la fenêtre sub-état ~1–5ms ciblée par les attaques single-packet.

from django.db import transaction
 
def complete_order_atomic(checkout_id, user):
    with transaction.atomic():
        checkout = (
            Checkout.objects
            .select_for_update()  # row-level lock — serializes concurrent requests
            .get(id=checkout_id, user=user)
        )
        if checkout.current_step != CheckoutState.PAYMENT_CONFIRMED:
            raise WorkflowStateError(
                current=checkout.current_step,
                required=CheckoutState.PAYMENT_CONFIRMED,
            )
        checkout.current_step = CheckoutState.COMPLETE
        checkout.save()
        order = create_order(checkout)
    return order

Le SELECT FOR UPDATE est la ligne la plus importante pour la défense contre les races — sans lui, deux requêtes concurrentes peuvent toutes deux observer PAYMENT_CONFIRMED, toutes deux faire passer l'état à COMPLETE, et toutes deux créer des commandes. Avec lui, la seconde requête bloque jusqu'au commit de la première, relit le nouvel état, et est rejetée. Combiné avec l'application FSM et les webhooks vérifiés HMAC, cela ferme la classe de contournement de workflow contre l'attaque classique de saut et le CWOB single-packet HTTP/2.

Sujets liés#

• Contournement de limite — Contournement d'application UI-only via appels API directs.
• Manipulation de prix — Souvent chaîné au contournement de workflow pour fixer le prix à zéro avant de sauter le paiement.
• Empilement de coupons — Les race conditions sur endpoints coupons partagent le même primitif single-packet attack.
• Failles de logique métier (vue d'ensemble) — Page pilier couvrant les 6 variantes.

Ressources#

• OWASP WSTG-BUSL-06 — Testing for the Circumvention of Work Flows
• PortSwigger — Smashing the State Machine: The True Potential of Web Race Conditions (James Kettle, août 2023)
• OWASP Top 10 for Business Logic Abuse — Workflow Order Bypass
• CWE-841 — Improper Enforcement of Behavioral Workflow