reentrancy-attack
リエントランシー攻撃は、スマートコントラクトの再帰的な呼び出しに対する脆弱性を悪用し、攻撃者が最初のトランザクションが完了する前に資金を繰り返し引き出したり、コントラクトの状態を操作したりすることを可能にします。
リエントランシー攻撃は、悪意のあるコントラクトが最初の呼び出しの実行が完了する前に、脆弱なコントラクトを呼び出すことによって発生します。この再帰的な呼び出しは、資金を枯渇させたり、コントラクトの状態を意図しない方法で変更したりする可能性があります。この脆弱性は、コントラクトが外部呼び出し、特にその内部状態を潜在的に操作する可能性のあるものを適切に考慮しない場合に発生します。これは、ユーザーとプロジェクトにとって大きな金銭的損失につながる可能性があるため、分散型アプリケーション（dApps）における重要なセキュリティ上の懸念事項です。
graph LR
Center["reentrancy-attack"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_smart_contracts["smart-contracts"]:::related -.-> Center
click Rel_smart_contracts "/terms/smart-contracts"
Rel_smart_contract_vulnerability["smart-contract-vulnerability"]:::related -.-> Center
click Rel_smart_contract_vulnerability "/terms/smart-contract-vulnerability"
Rel_smart_contract_security["smart-contract-security"]:::related -.-> Center
click Rel_smart_contract_security "/terms/smart-contract-security"
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;
🧠 理解度チェック
🧒 5歳でもわかるように説明
It's like going to an ATM, withdrawing money, but before the machine updates your balance, you quickly ask it again for money, and it lets you take more because it hasn't realized you already took some!
🤓 Expert Deep Dive
Reentrancy attacks exploit the asynchronous nature of external calls in smart contract execution environments. In Ethereum's EVM, when a contract sends Ether using call.value()(), the receiving contract's fallback function or receive function is executed. If this fallback logic contains a call back to the sending contract's vulnerable function (e.g., withdraw()), the execution stack allows this recursive call. The attacker's contract can manipulate the msg.sender context or internal state variables within the re-entered function call. The Checks-Effects-Interactions pattern is a fundamental security principle to prevent this; state changes must be finalized before external calls are made. For instance, updating the user's balance to zero before sending the Ether prevents the re-entered call from seeing a non-zero balance. Reentrancy guards, often implemented as a state variable toggled during function execution, act as a mutex to prevent re-entry. However, care must be taken to ensure the guard is correctly reset, especially in complex interaction chains.