Le développement de l'écosystème de la finance décentralisée (DeFi) et du Web3 a apporté des changements révolutionnaires dans la façon dont les gens interagissent avec les actifs numériques. Cependant, derrière la commodité des transactions automatisées se cache une structure d'autorisation complexe, dans laquelle le compromis entre l'expérience utilisateur (UX) et la sécurité crée d'énormes vulnérabilités. Les droits d'accès dans les contrats intelligents sont plus qu'un simple bouton « approuver » ; il s’agit d’un mécanisme de délégation de propriété d’actifs qui, s’il est abusé, peut conduire à l’épuisement d’un portefeuille entier en une seule transaction. Selon Tan Phat Digital, ce rapport approfondira l'analyse des risques techniques liés à l'approbation infinie des jetons, aux attaques de phishing via des signatures hors chaîne, aux risques centralisés dans la gouvernance des protocoles et proposera une feuille de route de sécurité basée sur la pensée Zero Trust et la gestion des accès basée sur les rôles (RBAC). Pour effectuer des opérations telles que l'échange sur des échanges décentralisés (DEX) ou la cotation de NFT, les utilisateurs doivent autoriser les contrats intelligents via un mécanisme appelé Token Approval.
Structure en trois étapes du mécanisme d'autorisation
Les normes ERC-20 et ERC-721 définissent un protocole spécifique pour effectuer des transferts au nom des utilisateurs. Ce mécanisme comprend trois composants principaux :
Fonction d'approbation (dépensier, montant) : approuve les droits d'accès. Le rôle technique est de mettre à jour le mappage du solde autorisé à dépenser sur l'état de la Blockchain.
Allocation de fonction (propriétaire, dépensier) : vérifie les autorisations. Le rôle technique est d'interroger la quantité de jetons qu'une adresse spécifique est autorisée à retirer au propriétaire.
Fonction transferFrom(from, to, montant) : exécute le mouvement des actifs. Le rôle technique est de retirer les jetons du portefeuille de l'utilisateur et de les transférer à l'adresse cible.
Lorsque l'utilisateur appelle la fonction d'approbation, il enregistre un engagement immuable sur la blockchain selon lequel l'adresse du dépensier a le droit de retirer jusqu'à un certain nombre de jetons de son adresse. Le danger réside dans le fait que la fonction transferFrom peut être appelée par le contrat intelligent à tout moment dans le futur sans aucune autre confirmation de la part de l'utilisateur, tant que la quantité de tokens demandée reste dans la limite autorisée.
Voir aussi : Qu'est-ce que la révocation d'approbation ?
Le paradoxe de la commodité : des jetons d'approbation infinis
En réalité, pour optimiser l'expérience et minimiser les coûts de gaz, la plupart des applications décentralisées (dApps) exigent que les utilisateurs accordent des autorisations « infinies » (généralement le valeur maximale d'une variable entière $2^{256} - 1$). Cela permet aux utilisateurs de ne payer que les frais d'essence pour une seule approbation au lieu d'avoir à signer pour chaque transaction.
Cependant, cette commodité a un prix élevé en termes de sécurité. Une fois les droits d’approbation illimités accordés, ils existeront en permanence sur la blockchain jusqu’à ce qu’ils soient explicitement révoqués. Même si l'utilisateur a déconnecté le portefeuille du site Web de l'application, cette autorité reste en chaîne, permettant au contrat intelligent d'accéder aux actifs à tout moment. Si ce contrat intelligent échoue ou est contrôlé par un attaquant, le solde total de ce jeton dans le portefeuille de l'utilisateur sera immédiatement vidé.
Analyse de la vulnérabilité et de la perpétuité du stockage
Les données d'approbation ne se trouvent pas dans le portefeuille de l'utilisateur mais dans le stockage (stockage) de ce contrat de jeton. Cela crée un angle mort cognitif : les utilisateurs vérifient souvent le solde du portefeuille mais consultent rarement la liste des entités qui ont le pouvoir de « débloquer » ce solde. Selon les statistiques de la plateforme Revoke, plus de 475 millions USD ont été volés depuis 2020 en raison de vulnérabilités liées à l'abus des droits d'approbation. Tan Phat Digital souligne qu'il ne s'agit pas seulement d'un défaut technique mais également d'un échec dans la conception de l'expérience utilisateur (UX) de l'ensemble de l'industrie Web3.
L'évolution des attaques de phishing grâce au mécanisme d'approbation hors chaîne
Alors que la communauté cherche des moyens de réduire les tracas liés aux frais de gaz par approbation, de nouvelles normes telles que EIP-2612 (permis) et Uniswap Permit2 ont vu le jour. Bien qu'ils offrent des avantages en termes de coûts, ils ouvrent de nouvelles voies pour des attaques de phishing plus sophistiquées.
Mécanismes d'autorisation et risques associés
Approbation ERC-20 : autorisation via des transactions en chaîne. Il a l'avantage d'être transparent et facile à suivre, mais l'inconvénient est qu'il coûte du gaz pour chaque exécution et comporte des risques potentiels s'il accorde des autorisations illimitées.
Permis EIP-2612 : octroi d'autorisations via une signature hors chaîne. Aide les utilisateurs à éviter les frais d'essence, mais est vulnérable aux attaques de phishing de type « signature aveugle » car les messages de signature sont souvent difficiles à lire et les anomalies difficiles à détecter.
Permis 2 : signature basée sur une approbation préalable. Offre une flexibilité supérieure et une gestion centralisée, mais s'il est amené à signer un message Permit2 malveillant, l'attaquant pourrait drainer tous les jetons approuvés pour ce contrat.
EIP-7702 : le « cheval de Troie » des portefeuilles EOA
Introduit dans la mise à niveau de Pectra en mai 2025, l'EIP-7702 permet aux comptes des parties propriétaires (EOA) de se « transformer » temporairement en un contrat intelligent. portefeuille. L'attaquant incite l'utilisateur à signer une autorisation pour un contrat de « gouvernante » malveillant. Une fois cette autorisation activée, l'attaquant peut installer une logique de retrait automatique directement dans le compte de la victime. Les données de Dune Analytics montrent qu'en juin 2025, plus de 97 % des transactions proxy EIP-7702 ciblaient des contrats malveillants liés à des activités criminelles.
Risques liés aux droits d'administrateur centralisés et aux fonctions privilégiées
En plus des risques pour les utilisateurs, la structure d'autorité au sein des protocoles eux-mêmes constitue également une menace. Des défauts de centralisation se produisent lorsqu'une conception crée une seule faiblesse qui peut provoquer l'effondrement de l'ensemble du système.
Fonction Mint avec signature unique (MFS) : permet à une seule adresse d'imprimer un nombre illimité de jetons, conduisant à une hyperinflation.
Gestion sans Timelock (MT) : des changements importants peuvent être mis en œuvre immédiatement, laissant la communauté incapable de réagir à temps.
Variable critique Manipulation (CVS) : un compte unique avec le pouvoir de modifier les taux d'intérêt, les paramètres de risque ou les flux de données (oracle).
Single Proxy Admin (SPA) : une adresse qui contrôle le droit de mettre à niveau l'ensemble de la logique du contrat intelligent.
Comme le rapporte Chainalysis, environ 43,8 % des fonds volés lors des piratages de la blockchain proviennent de l'exposition de clés privées privilégiées. comptes.
Voir aussi : Quelle est la dangerosité de l'arnaque à l'approbation
Analyse technique du risque de mises à niveau et de collisions de stockage (Storage Collision)
Les protocoles DeFi utilisent souvent le modèle Proxy pour corriger les erreurs ou ajouter des fonctionnalités. Cependant, ce mécanisme repose sur l'appel délégué, qui comporte un risque de collisions de stockage. Si l'ordre des variables dans le nouveau contrat logique n'est pas correct par rapport à l'ancien contrat, les valeurs stockées seront écrasées. Un attaquant peut en profiter pour diriger le proxy vers un contrat logique malveillant, drainant ainsi les actifs de l'utilisateur.
De plus, les vulnérabilités Initializer Vulnerability sont également très courantes. Si le développeur oublie de protéger la fonction d'initialisation, un attaquant peut appeler cette fonction pour s'identifier en tant que propriétaire et prendre le contrôle de l'ensemble du système.
Leçons d'attaques réelles
L'analyse des incidents historiques aide Tan Phat Digital à montrer comment les vulnérabilités d'autorisation sont exploitées dans la pratique :
Step Finance (janvier 2026) : dommages d'environ 30 millions de dollars. L'attaquant a infiltré les appareils de l'équipe d'exploitation, accédant ainsi aux portefeuilles de trésorerie et effectuant des retraits de 261 854 SOL.
CrossCurve (février 2026) : dégâts de 3 millions USD. L'attaque exploite une erreur d'implémentation dans la logique des messages inter-chaînes, permettant aux attaquants d'envoyer des messages usurpés pour contourner l'authentification et effectuer des retraits non autorisés.
Radiant Capital (octobre 2024) : perte de 50 millions USD. Les logiciels malveillants ont infecté les appareils des développeurs, remplaçant silencieusement la charge utile des transactions multisig pour transférer la propriété du contrat à l'attaquant.
Poly Network (2021) : 611 millions de dollars de dégâts. Les erreurs de logique d'accès permettent la manipulation des paramètres d'entrée via des appels inter-chaînes.
Bybit (février 2025) : un vol record avec des pertes de près de 1,5 milliard de dollars dans Ethereum, montrant l'ampleur dévastatrice des vulnérabilités d'autorisation.
Solution recommandée : cadre de sécurité Zero Trust pour les contrats intelligents
Face à la complexité de l'attaque, adopter une L'état d'esprit Zero Trust est indispensable :
Toujours s'authentifier en continu : chaque demande d'accès aux actifs doit être authentifiée au moment de l'exécution.
Droits d'accès réels (RBAC) : divisez les autorisations en rôles spécifiques tels que Minter, Pauser au lieu d'attribuer des droits de propriétaire complets.
Les hypothèses du système ont été compromises : déployez un circuit automatique. disjoncteurs et surveillance en temps réel.
Foire aux questions (FAQ)
1. Qu'est-ce que l'approbation de jeton et pourquoi les dApps en ont-elles besoin ? L'approbation de jeton est une autorisation en chaîne que vous accordez à un contrat intelligent afin qu'il puisse accéder à une quantité spécifique de jetons dans votre portefeuille sans nécessiter de signature pour chaque action de transaction individuelle.
2. L'octroi d'autorisations « illimitées » (approbation illimitée) est-il sûr ? Pas sûr. Si la dApp est piratée ou constitue une arnaque, l'attaquant peut utiliser cette autorisation pour vider complètement ce jeton de votre portefeuille à tout moment.
3. Si je déconnecte le portefeuille du site Web, les autorisations accordées seront-elles révoquées ? Non. La déconnexion empêche uniquement le site Web de voir l'adresse de votre portefeuille. L'autorité d'approbation reste permanente sur la blockchain jusqu'à ce que vous effectuiez une transaction de révocation spécifique.
4. Puis-je perdre tous les actifs de mon portefeuille à cause d'une seule approbation ? Une transaction d'approbation ne s'applique généralement qu'à un jeton spécifique (par exemple, uniquement WETH). Un attaquant ne peut s'en sortir qu'avec les jetons que vous avez approuvés, à moins que vous ne signiez des autorisations plus complexes comme SetApprovalForAll pour les NFT.
5. Comment vérifier la liste des autorisations que j'ai accordées ? Vous pouvez utiliser des outils réputés tels que Revoke.cash, Etherscan Token Approval Checker ou De.Fi Shield pour analyser toutes les autorisations actives sur différents réseaux.
6. En quoi le permis (EIP-2612) est-il différent de l'approbation traditionnelle ? L'approbation nécessite une transaction en chaîne qui coûte du gaz immédiatement. Le permis utilise des signatures hors chaîne, permettant d'approuver les autorisations sans consommer de gaz pour l'utilisateur (les frais de gaz sont généralement payés par le protocole lorsque la transaction est effectuée ultérieurement).
7. Que dois-je faire si je signe accidentellement un permis/signature hors chaîne sur un site suspect ? Vous devez immédiatement accéder à vos outils de révocation pour vérifier si la signature a été activée en chaîne. Cependant, la destruction des signatures hors chaîne est difficile car les attaquants les exécutent souvent presque immédiatement.
8. Pourquoi les portefeuilles multisig (comme Safe) peuvent-ils encore être piratés ? Les portefeuilles multisig piratés sont souvent causés par l'infection des appareils des propriétaires par des logiciels malveillants, permettant aux attaquants de remplacer le contenu réel des transactions par des transactions malveillantes à l'insu de l'utilisateur lors de la signature (phishing d'interface).
9. Qu'est-ce que le timelock et pourquoi le projet en a-t-il besoin ? Timelock est un mécanisme permettant de retarder l'exécution des commandes administratives (par exemple, un délai de 48 heures). Cela donne à la communauté le temps de tester les modifications et de retirer les actifs si des profits de la part de l'administrateur sont détectés.
10. Quelle est la différence entre le risque technique et le risque administratif (risque de centralisation) ? Le risque technique provient d'erreurs logiques dans le code (comme la réentrance). Le risque de gouvernance provient d'une concentration excessive de l'autorité entre les mains d'un seul individu, lui permettant de modifier des paramètres importants ou de mettre à niveau des contrats de manière arbitraire.
11. Qu'est-ce que le modèle de conception « approuver à zéro puis définir » ? Il s'agit d'un processus de sécurité qui oblige les utilisateurs à ramener le niveau d'approbation à zéro avant de définir un nouveau niveau d'approbation, afin d'éviter les attaques par condition de concurrence dans certaines anciennes normes de jetons.
12. Quels avantages en matière de sécurité l'EIP-7702 apporte-t-il ? L'EIP-7702 permet aux portefeuilles d'effectuer des « intentions de session », regroupant les approbations et les actions en une seule transaction, minimisant ainsi la possibilité de suspension d'autorisations illimitées sur la blockchain une fois la transaction terminée.
13. Quand un projet doit-il être réaudité ? Un projet doit être réaudité chaque fois qu'il y a des modifications majeures du code, des mises à niveau de la logique contractuelle ou des intégrations avec de nouveaux protocoles tiers pour garantir qu'aucune nouvelle vulnérabilité n'est introduite.
14. Comment vérifier qu'un contrat intelligent est sûr ? Il est nécessaire de vérifier s'il dispose de rapports d'audit d'entreprises réputées, d'un historique d'activité sur le testnet, d'un programme de bug bounty et si le code source est accessible au public sur les explorateurs de blocs.
15. Les Cold Wallets (Hardware Wallets) me protègent-ils des attaques de phishing ? Les Cold Wallets protègent vos clés privées contre le vol par des logiciels malveillants. Cependant, cela ne peut pas vous empêcher de signer une transaction malveillante si vous êtes trompé (signature aveugle). Vous devez toujours vérifier les paramètres sur l’écran du cold wallet avant de confirmer.
Tan Phat Digital recommande aux utilisateurs finaux d'utiliser des outils tels que Revoke.cash, De.Fi Shield ou Etherscan Token Approval pour vérifier et révoquer périodiquement l'autorisation. Lors de la signature de transactions, utilisez toujours la fonctionnalité « Modifier l'autorisation » pour limiter le nombre de jetons au lieu d'accepter le niveau d'approbation illimité par défaut.
Les autorisations dans les contrats intelligents sont en réalité plus dangereuses qu'on ne l'imagine. La combinaison étroite de solutions techniques et de réflexion Zero Trust constitue la base essentielle pour construire un écosystème Web3 durable et digne de confiance.
Partager
