L'IA détecte le risque de double dépense dans le cas de TOCTOU
Les conditions de course au moment de la vérification et au moment de l'utilisation sont une catégorie de bogues temporels qui comblent l'espace entre le point de décision d'un système et le moment où cette décision est mise en œuvre. Dans les flux de paiement de la blockchain, un tel écart peut faire la différence entre un seul achat valide et une double dépense. Lorsque le code lit un solde, puis applique plus tard un achat, un attaquant qui peut soumettre des transactions presque simultanées ou exploiter le réordonnancement peut faire en sorte que la vérification réussisse deux fois alors que la mise à jour de l'état ne se produit qu'une seule fois. C'est le cœur de la TOCTOU à double dépense.
Fonctionnement de la négligence
L'approche de Penligent pour trouver ces problèmes n'est pas une devinette. Elle commence par des modèles d'analyse statique qui signalent les idiomes "check-then-act" - des lignes de code où l'équilibre ou le droit est lu et où une écriture ultérieure met à jour un compteur de droits. Ces emplacements marqués reçoivent un contexte : le graphe d'appel du chemin de code, le point de terminaison du réseau qui l'invoque et les hypothèses environnementales qu'il fait (par exemple, "suppose des mises à jour à un seul fil" ou "suppose des confirmations de bloc avant l'étape suivante"). Avec ce contexte, Penligent déclenche une vérification contrôlée : des sondes non-destructives contre des points de terminaison de mise en scène, la corrélation avec des traces de transactions lorsqu'elles sont disponibles, et des tests de concurrence ciblés qui échantillonnent le comportement lors de soumissions quasi-simultanées.
Concrètement, un flux vulnérable peut ressembler à ceci en production : l'application vérifie balance[shop_address] == 1_000_000 et incrémente ensuite le nombre de diamants de l'acheteur. Un attaquant soumet deux transactions de 1 000 000 DDCoin qui arrivent dans la fenêtre entre la vérification et le changement d'état effectif. Comme la vérification s'exécute avant que l'une ou l'autre transaction ne soit validée, les deux vérifications sont réussies et l'utilisateur gagne deux diamants tout en ne dépensant qu'une seule unité de l'actif. Penligent rassemble les preuves en collectant les traces de demande/réponse, les identifiants de transaction, les horodatages de bloc et tout artefact de course observable, puis les lie à l'emplacement du code statique qui effectue la vérification.
Comment réparer TOCOTOU
La correction de TOCTOU dans les contextes de blockchain signifie généralement que la vérification de l'équilibre et le changement d'état doivent être atomiques. Sur les backends traditionnels, cela signifie des transactions de base de données avec des niveaux d'isolation forts et des mutex ou des schémas de concurrence optimistes avec des tentatives. Sur les contrats intelligents, cela signifie concevoir le contrat de sorte que les transitions d'état soient exécutées en une seule transaction, ou utiliser des mécanismes tels que les nonces et les numéros de séquence explicites par compte pour empêcher les opérations rejouées ou dupliquées. Le pseudocode sûr suivant montre le modèle défensif, en mettant l'accent sur l'atomicité et la correction plutôt que sur l'attaquabilité :
# pseudocode défensif : mise à jour atomique à l'intérieur d'une transaction sérialisable
avec db.transaction(isolation="serializable") :
si solde[adresse_magasin] >= PRIX :
solde[adresse_magasin] -= PRIX
session["vos_diamants"] += 1
sinon :
raise InsufficientBalanceError()
Sur le plan opérationnel, des mesures supplémentaires sont utiles : exiger des nonces ou des compteurs monotones dans les soumissions de transactions, maintenir un ordre strict des opérations au niveau de la passerelle API et mettre en place une traçabilité complète afin de pouvoir reconstituer les schémas de soumissions concurrentes. La limitation du débit et la mise en lots peuvent également réduire la fenêtre pratique dans laquelle la concurrence peut être exploitée.
Du point de vue de la détection, la valeur réelle de Penligent réside dans la fusion des signaux. Les indicateurs statiques seuls génèrent de nombreux faux positifs ; la télémétrie d'exécution seule n'a pas de lien direct avec le code source. Penligent relie les résultats des codes statiques aux preuves d'exécution réelles : quels points d'extrémité ont été appelés, quels identifiants de transaction ont été observés sur la chaîne et quelle séquence d'événements a conduit à une divergence d'état. Le résultat est un ensemble de preuves qui sont exploitables : les développeurs reçoivent les lignes de source exactes à corriger, les opérations obtiennent les traces de transaction pour valider un renversement ou une atténuation, et les équipes de sécurité obtiennent un plan de remédiation priorisé.
Pour les équipes qui adoptent ce modèle, le flux de travail devient plus rapide et plus responsable. Au lieu de mois de triage manuel, vous obtenez des preuves reproductibles et un chemin de remédiation clair. La solution relève autant de l'ingénierie que du processus : les propriétaires de produits doivent accepter les contraintes d'atomicité, les opérations doivent garantir l'isolation transactionnelle lors du déploiement et la sécurité doit valider les mesures d'atténuation à l'aide de réexécutions ciblées.
Suggestion d'invite pénligente (langage naturel) - pour usage interne
Si vous souhaitez que Penligent recherche les risques de double dépense de type TOCTOU sur un service donné, une invite concise pourrait être la suivante :
"Scanner le point de terminaison des paiements à l'adresse https://staging.example.com/create_transaction pour les conditions de course TOCTOU et de double dépense. Se concentrer sur les chemins de code qui lisent les soldes ou les droits puis écrivent l'état. Générer des échantillons de vérification non destructifs, corréler les traces de transactions simultanées et produire un ensemble de preuves avec l'emplacement des sources et les correctifs prioritaires".
Cette invite indique à Penligent de combiner la recherche de motifs statiques avec la validation d'exécution sûre et la corrélation de preuves.
