reentrancy-attack
Атака повторного входа использует уязвимость смарт-контракта к рекурсивным вызовам, позволяя злоумышленнику многократно выводить средства или манипулировать состоянием контракта до завершения первоначальной транзакции.
A reentrancy attack is a vulnerability in smart contracts, particularly prevalent in platforms like Ethereum, that exploits the ability of a contract to call back into itself or another contract before the initial execution context has finished. This typically occurs when a contract performs an external call to another contract (e.g., sending Ether) before updating its internal state (e.g., balance). If the called contract is malicious, it can initiate a new call back to the original contract, re-entering its functions. The attacker can repeatedly execute the vulnerable function, such as a withdrawal, before the contract's state is updated to reflect the first withdrawal. This allows the attacker to drain funds far exceeding their actual balance. A common mitigation is the Checks-Effects-Interactions pattern, where all internal checks are performed first, followed by state changes (effects), and only then are external interactions (like sending Ether) executed. Using reentrancy guards (mutexes) or the nonReentrant modifier in Solidity can prevent recursive calls within a single transaction. Ensuring that state updates happen before external calls is crucial for preventing this class of vulnerability.
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;
🧠 Проверка знаний
🧒 Простыми словами
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.