Attaque de réentrance : comprendre, prévenir et agir
Les attaques de réentrance figurent parmi les vulnérabilités les plus redoutées en smart contracts. Elles surviennent lorsqu’un contrat appelle un externe avant d’avoir mis à jour son propre état : l’attaquant peut alors « ré-entrer » dans la fonction et répéter l’action (ex. retrait) jusqu’à drainer les fonds. Voir la définition OWASP :
SC05 — Reentrancy.
1) Principe en 3 étapes
- Checks (vérifier les conditions)
- Effects (mettre à jour l’état)
- Interactions (appels externes)
Le bon pattern est Checks → Effects → Interactions (CEI) : d’abord les validations, puis la mise à jour d’état, puis seulement l’appel externe. Réf. bonnes pratiques :
Ethereum.org — Security.
2) Cas d’école : The DAO (2016)
L’attaque de The DAO illustre parfaitement la réentrance (retraits répétés avant mise à jour de l’état), menant au fork Ethereum / Ethereum Classic. Lecture recommandée :
Chainlink — Reentrancy & The DAO hack.
3) Variantes à connaître
- Single-function reentrancy : ré-entrée sur la même fonction vulnérable.
- Cross-function : ré-entrée via une autre fonction du même contrat.
- Cross-contract / Read-only : via des interactions entre contrats.
- Cross-chain : scénarios multi-chaînes interopérables.
Un aperçu pédagogique :
Morpher (FR) — Attaque de réentrance et
Cyfrin — Tutoriel Solidity.
4) Vulnérabilités connexes à surveiller
- Overflow / Underflow (arithmétique) : lire
OWASP — Integer Overflow/Underflow. - Front-running / MEV (ré-ordonnancement de transactions) :
MEV — Ethereum.org. - Unchecked external calls / erreurs de logique :
OWASP SC Top 10 (vue d’ensemble).
5) Prévention et techniques concrètes
- Applique CEI systématiquement (cf.
Ethereum.org — Security). - Garde de réentrance (
nonReentrant
) via
OpenZeppelin — ReentrancyGuard. - Modèle Pull-Payments (les bénéficiaires retirent eux-mêmes) :
OpenZeppelin — PullPayment. - Audits & tests (invariants, fuzzing) et revues régulières :
ConsenSys — Best Practices.
🔒 Protégez vos smart contracts dès aujourd’hui
Mettez en place CEI, ReentrancyGuard, des tests d’invariants et des audits indépendants. La sécurité conditionne la confiance et l’adoption.
- Audit préventif et revue de code
- Mise en place des garde-fous OpenZeppelin
- Plan de tests (unitaires & fuzzing)
Ressources utiles
- OWASP : SC05 — Reentrancy
- OpenZeppelin : ReentrancyGuard | PullPayment
- ConsenSys : Smart Contract Best Practices
- Chainlink : Reentrancy & The DAO hack
- Morpher (FR) : Attaque de réentrance
- Quantstamp : What is a Re-Entrancy Attack?