Attaque de Frappe Infinie
Definition pending verification.
Une attaque de frappe infinie, souvent appelée 'glitch de frappe' ou 'vulnérabilité de réentrance' dans le contexte des smart contracts, est un type d'exploit où un attaquant manipule la logique d'un contrat pour frapper une quantité arbitrairement grande de tokens ou d'actifs. Cela se produit généralement dans les protocoles de finance décentralisée (DeFi), en particulier ceux impliquant des mécanismes de frappe de tokens, de prêt ou de mise en garantie. La vulnérabilité principale réside souvent dans la manière dont le contrat gère les appels externes ou met à jour son état interne pendant une transaction. Par exemple, un contrat pourrait permettre à un utilisateur de déposer une garantie, de frapper un nouveau token basé sur cette garantie, puis de retirer la garantie, le tout au sein d'une seule transaction. Si le contrat frappe le nouveau token avant de vérifier le dépôt de garantie ou de mettre à jour correctement son état interne, un attaquant pourrait déclencher la fonction de frappe plusieurs fois dans le même contexte de transaction. Chaque appel pourrait frapper plus de tokens basés sur la même garantie initiale (ou insuffisamment vérifiée), conduisant à la création de quantités 'infinies' ou massivement gonflées de tokens à partir de rien. Cela dévalue le token et peut drainer les réserves du protocole. La prévention de telles attaques nécessite une conception minutieuse des smart contracts, y compris l'utilisation du modèle 'Checks-Effects-Interactions' (Vérifications-Effets-Interactions), des gardes de réentrance, des mises à jour d'état appropriées avant les appels externes, et des audits approfondis.
graph LR
Center["Attaque de Frappe Infinie"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_consciousness_simulation_hardware["consciousness-simulation-hardware"]:::related -.-> Center
click Rel_consciousness_simulation_hardware "/terms/consciousness-simulation-hardware"
Rel_cognitive_enhancement["cognitive-enhancement"]:::related -.-> Center
click Rel_cognitive_enhancement "/terms/cognitive-enhancement"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explique-moi comme si j'avais 5 ans
Imaginez une machine à biscuits magique qui est censée vous donner un biscuit pour chaque pièce d'or que vous y mettez. Si la machine est cassée, vous pourriez être capable de mettre une pièce, obtenir un biscuit, puis utiliser *ce* biscuit pour tromper la machine en lui faisant croire que vous avez mis une autre pièce, obtenant ainsi des biscuits à l'infini !
🤓 Expert Deep Dive
Les attaques de frappe infinie exploitent des failles dans la logique de transition d'état des smart contracts, souvent liées à la réentrance ou à une mauvaise gestion des appels externes. Un schéma courant implique une fonction qui : 1) Accepte l'entrée de l'utilisateur (par exemple, la garantie). 2) Effectue un appel externe (par exemple, vers un contrat de token ERC777 qui déclenche un rappel). 3) Met à jour l'état interne (par exemple, frappe des tokens, met à jour les soldes). Si l'appel externe déclenche un appel réentrant vers la fonction d'origine avant que l'état ne soit mis à jour (par exemple, la garantie n'est pas entièrement comptabilisée ou le solde n'est pas ajusté), l'attaquant peut l'exploiter. Par exemple, dans un protocole de prêt, un utilisateur dépose une garantie C, appelle mint(montant_du_prêt), qui appelle en interne un contrat de token externe. La fonction de rappel de ce contrat de token réentre dans la fonction mint, permettant à l'attaquant de frapper à nouveau en utilisant la même garantie C avant que le premier appel mint ne termine sa mise à jour d'état. Le modèle 'Checks-Effects-Interactions' est crucial : vérifier les conditions (Checks), mettre à jour l'état interne (Effects), puis interagir avec les contrats externes (Interactions). Les gardes de réentrance (mutex) peuvent également empêcher les appels récursifs dans le même contexte de transaction. Des vulnérabilités peuvent également découler des capacités de réentrance d'ERC777 ou d'implémentations ERC20 défectueuses.