Attaque par rejeu

Qu’est-ce qu’une attaque par rejeu ?

Une attaque par rejeu consiste à soumettre à nouveau au système une transaction ou une autorisation précédemment valide, entraînant ainsi son exécution répétée. C’est comme copier un document signé et le présenter à différents guichets pour obtenir plusieurs tampons.

Dans la blockchain, les signatures sont générées à partir de clés privées, agissant comme des sceaux numériques pour confirmer : « J’approuve cette action. » Si une transaction signée est reconnue dans d’autres contextes, elle devient exposée au rejeu.

Pour éviter toute duplication, les blockchains utilisent un identifiant unique appelé nonce. Le nonce fonctionne comme un numéro de série propre à chaque opération, jamais réutilisé. Le système n’accepte que les nonces encore inutilisés.

Dans les environnements cross-chain ou lors d’un fork, un chainId s’avère également indispensable. Le chainId sert d’identifiant réseau, liant la transaction à une chaîne précise et empêchant son rejeu sur une autre.

Pourquoi les attaques par rejeu surviennent-elles ?

Les attaques par rejeu se produisent généralement lorsque le système ne précise pas explicitement le « contexte » d’une action. Ce contexte englobe la blockchain concernée, la présence d’un identifiant unique, une éventuelle date d’expiration, ou encore l’association à un domaine ou à un smart contract spécifique.

Si une signature ne prouve que le consentement à une action sans préciser la chaîne, l’application ou la période de validité, toute personne disposant de cette signature peut la réutiliser dans un autre environnement.

Si une application ne gère l’état « utilisé ou non utilisé » qu’en local ou en cache, sans enregistrement sur la blockchain, les attaques par rejeu deviennent plus simples à réaliser. De même, après un fork, si les deux chaînes partagent le même format de transaction et les mêmes nonces, le rejeu cross-chain est possible.

Comment les attaques par rejeu sont-elles menées sur la blockchain ?

Pour un rejeu sur la même chaîne, l’attaquant intercepte un message d’autorisation ou une transaction spécifique et la soumet à nouveau sur la même chaîne. Ce scénario survient souvent lorsque les « autorisations de signature hors ligne » ne comportent ni nonce unique ni horodatage d’expiration.

Dans le cas d’un rejeu cross-chain, les transactions ou messages ne sont pas liés à un chainId, ou bien, après un fork, les deux chaînes acceptent le même format de signature. L’attaquant peut alors exécuter une transaction valide de la chaîne A sur la chaîne B.

Au niveau des smart contracts, si les contrats ne suivent pas les identifiants de messages traités ou manquent d’idempotence (c’est-à-dire que des appels répétés produisent des effets cumulatifs), l’attaquant peut déclencher plusieurs fois des opérations initialement prévues pour une seule exécution.

Exemples concrets d’attaques par rejeu

En 2016, Ethereum a connu une scission de chaîne, donnant naissance à ETH et ETC. Les premières transactions ne différenciant pas les chaînes, des risques de rejeu cross-chain sont apparus. L’EIP-155, introduit cette année-là, a ajouté le chainId aux transactions, réduisant nettement ces attaques (voir l’historique des Ethereum Improvement Proposals).

Dans les scénarios d’autorisation, si les approbations par signature pour transferts ou plafonds de dépenses ne comportent ni expiration ni nonce unique, les signatures peuvent être resoumises. L’EIP-2612, introduit en 2020, a standardisé l’autorisation par signature des tokens ERC-20, rendant nonce et expiration obligatoires (voir Ethereum Improvement Proposal).

Si les bridges cross-chain et protocoles de messagerie n’attribuent pas d’identifiants uniques ni ne suivent les messages consommés, les attaques par rejeu peuvent entraîner la création ou la libération répétée d’actifs. Le secteur atténue désormais ces risques en utilisant des IDs de messages et le suivi d’état on-chain.

Comment détecter les indices d’une attaque par rejeu ?

Commencez par vérifier le contenu de toute demande de signature. Si votre portefeuille vous propose une « signature à l’aveugle » (sans détails clairs sur la transaction, le domaine ou la chaîne), le risque de rejeu est accru.

Puis, assurez-vous que l’autorisation comporte une date d’expiration et un nonce unique. L’absence de l’un ou de l’autre augmente votre exposition.

Vérifiez la présence d’un contexte de chaîne explicite. L’absence de chainId ou de séparation de domaine (par exemple dans les domaines EIP-712) accroît le risque de rejeu entre environnements différents.

Enfin, surveillez tout signe d’exécution répétée inhabituelle : même autorisation utilisée plusieurs fois, transferts d’actifs répétés en peu de temps, ou messages identiques ayant des effets sur plusieurs chaînes.

Mesures techniques pour se protéger des attaques par rejeu

Étape 1 : Liez les transactions à leur contexte de chaîne. Utilisez le chainId de l’EIP-155 pour restreindre chaque transaction à sa chaîne cible et empêcher les replays cross-chain.

Étape 2 : Attribuez à chaque autorisation un nonce unique et une date d’expiration. Les standards EIP-2612 et Permit2 imposent que chaque signature comporte nonce et date limite ; les autorisations expirées sont invalidées.

Étape 3 : Enregistrez les messages ou nonces utilisés dans les smart contracts. Chaque message doit disposer d’un ID non réutilisable et son état de consommation doit être stocké on-chain pour garantir l’idempotence.

Étape 4 : Utilisez des signatures structurées selon l’EIP-712. Les signatures doivent inclure le nom de domaine (verifyingContract, name, version), le chainId et un contenu lisible, afin de limiter les abus et vecteurs de rejeu.

Étape 5 : Implémentez une validation bidirectionnelle dans les bridges cross-chain et les canaux de messagerie. Contrôlez non seulement les chaînes source et cible, mais aussi l’unicité du message, les numéros de lot et l’état de traitement pour empêcher toute exécution répétée par différentes routes.

Comment les utilisateurs peuvent-ils éviter les attaques par rejeu au quotidien ?

Étape 1 : Ne signez que sur des interfaces affichant des informations explicites. Refusez les signatures à l’aveugle : le message doit toujours contenir le domaine, la chaîne et la finalité.

Étape 2 : Limitez les autorisations accordées. Privilégiez les approbations à durée limitée et plafonnées, et révoquez régulièrement les droits inutilisés via des explorateurs blockchain ou outils de gestion. Lors d’un retrait sur Gate, vérifiez toujours le réseau et l’adresse sélectionnés pour éviter toute erreur cross-environment.

Étape 3 : Séparez vos fonds de vos portefeuilles opérationnels. Conservez les actifs principaux dans des hardware wallets ou portefeuilles en lecture seule ; utilisez de petits portefeuilles chauds pour interagir avec les DApps et limiter les pertes potentielles dues à des autorisations répétées.

Étape 4 : Utilisez un carnet d’adresses et des listes blanches. Enregistrez les adresses de destinataires fréquents dans le carnet d’adresses Gate et activez les listes blanches de retrait afin de réduire les risques liés aux erreurs ou aux signatures de phishing provoquant des soumissions multiples.

Étape 5 : Surveillez toute activité anormale. Si vous détectez des transactions ou autorisations en double sur une courte période, suspendez immédiatement vos opérations, révoquez les autorisations et vérifiez la sécurité de vos appareils et extensions.

En quoi l’attaque par rejeu diffère-t-elle d’une attaque de double dépense ou Sybil ?

L’attaque par rejeu consiste à resoumettre une transaction ou une autorisation valide, le problème étant l’exécution répétée. La double dépense vise à utiliser le même actif à deux reprises, impliquant généralement les mécanismes de consensus et la réorganisation des blocs—cela relève d’une différence fondamentale au niveau du protocole.

L’attaque Sybil consiste à utiliser plusieurs identités pour usurper de nombreux utilisateurs, manipuler des votes ou des distributions ; elle ne concerne pas la répétition de transactions, mais la fraude sur la couche identité. Les attaques par rejeu se situent au niveau transaction/message.

Par ailleurs, les attaques de type « man-in-the-middle » modifient généralement les données ou le routage, alors que les attaques par rejeu se bornent à resoumettre des données identiques sans modification du contenu.

Comment les attaques par rejeu évoluent-elles dans le Web3 ?

Depuis l’introduction du chainId par l’EIP-155 en 2016, les attaques de rejeu cross-chain ont nettement diminué ; l’EIP-2612 (2020) et Permit2 ont renforcé la standardisation des mécanismes de nonce et d’expiration pour les approbations par signature. À l’horizon 2025, avec l’essor des réseaux multi-chaînes et Layer 2, les canaux de messagerie, les IDs anti-rejeu et la conception idempotente deviennent des piliers d’infrastructure.

L’abstraction de compte (par exemple, ERC-4337) favorise la gestion des nonces par domaine et stratégies associées—l’utilisation de nonces distincts pour chaque opération réduit le risque de rejeu à l’intérieur d’un même domaine. Les bridges cross-chain privilégient la vérification de la source et le suivi d’identifiants uniques pour limiter les opportunités d’exécution répétée.

Résumé de l’attaque par rejeu et recommandations

L’attaque par rejeu consiste à exécuter un contenu valide dans un contexte inapproprié. Pour s’en prémunir, il faut clarifier le contexte : identifiants de chaîne, nonces uniques, dates d’expiration, association à un domaine, et consigner systématiquement les états consommés on-chain. Pour les développeurs : adoptez les standards EIP-155, EIP-712, EIP-2612/Permit2 et une conception idempotente. Pour les utilisateurs : évitez les signatures à l’aveugle, privilégiez les autorisations à durée limitée, séparez les portefeuilles par usage et activez les listes blanches sur les exchanges pour limiter les risques. Si vous constatez une répétition anormale impliquant des fonds, suspendez immédiatement toute opération et révoquez les autorisations.

FAQ

Les attaques par rejeu peuvent-elles entraîner la perte de mes actifs ?

Les attaques par rejeu ne permettent pas de voler directement vos actifs, mais peuvent conduire à des transactions répétées à des fins malveillantes. Par exemple, si vous transférez 100 tokens sur la chaîne A et qu’un attaquant rejoue cette transaction sur la chaîne B, vous risquez de perdre des fonds sur les deux chaînes. La meilleure défense consiste à utiliser des portefeuilles qui prennent en charge la vérification du chain ID et à faire preuve d’une vigilance accrue lors des opérations cross-chain.

Dois-je m’inquiéter des attaques par rejeu lors de transactions sur Gate ?

Les exchanges centralisés comme Gate intègrent plusieurs couches de sécurité ; les utilisateurs réguliers sont très peu exposés au risque d’attaque par rejeu lors de transactions sur la plateforme. Le risque principal apparaît lors de transferts cross-chain avec des portefeuilles auto-hébergés. Pour le trading spot ou sur produits dérivés sur Gate, les contrôles de risque de la plateforme assurent la sécurité de votre compte.

Des événements majeurs comme une fusion sur Binance peuvent-ils entraîner des attaques par rejeu à grande échelle ?

Les évolutions majeures de l’écosystème (fusions ou forks de chaînes) augmentent le risque d’attaques par rejeu. Toutefois, les projets mettent généralement en place des mesures de protection, notamment la mise à jour anticipée des chain IDs. En tant qu’utilisateur, attendez toujours les annonces officielles avant toute opération cross-chain pendant ces périodes de transition pour éviter de devenir une cible.

Si ma clé privée est compromise, une attaque par rejeu aggrave-t-elle les pertes ?

La fuite d’une clé privée constitue déjà une faille de sécurité majeure. Les attaques par rejeu aggravent le problème, car un attaquant peut non seulement déplacer des actifs sur une chaîne, mais aussi rejouer les transactions sur plusieurs chaînes, ce qui peut entraîner la perte de tous vos actifs similaires. Transférez immédiatement vos fonds vers un nouveau portefeuille, c’est la seule solution.

Comment l’EIP-155 permet-il de prévenir les attaques par rejeu ?

L’EIP-155 a introduit le chain ID, garantissant que chaque transaction porte un identifiant réseau unique, ce qui empêche son exécution sur d’autres chaînes. Les réseaux Ethereum actuels et les chaînes compatibles appliquent tous ce standard, ce qui rend la plupart des attaques par rejeu inopérantes. Choisir un portefeuille compatible EIP-155 est la méthode la plus simple pour se protéger.