Reentrancy attacks in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this vulnerable Solidity contract call?

Consider the following simplified Solidity contract vulnerable to reentrancy:

contract Vulnerable {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount);
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success);
        balances[msg.sender] -= _amount;
    }
}

If an attacker calls withdraw with a crafted fallback function that calls withdraw again before the balance is updated, what will be the final balance of the attacker after one initial withdrawal of 1 ether?

A The attacker can withdraw multiple times before balance updates, ending with more ether than deposited.

B The attacker can withdraw more than their balance, ending with a negative balance error.

C The attacker drains all their balance repeatedly, ending with 0 balance.

D The contract reverts due to require failure, so no ether is withdrawn.

💡 Hint

Think about when the balance is updated relative to the external call.

The contract sends ether before updating the balance, so the attacker can recursively call withdraw multiple times, draining more ether than they deposited.

🧠 Conceptual

intermediate

Which practice prevents reentrancy attacks in Solidity?

Which of the following is the best practice to prevent reentrancy attacks in Solidity smart contracts?

A Update the user balance after sending ether to the user.

B Use <code>transfer</code> or <code>send</code> instead of <code>call</code> to send ether.

C Update the user balance before sending ether to the user.

D Allow unlimited gas in external calls to avoid failures.

💡 Hint

Think about the order of state changes and external calls.

Updating the balance before sending ether ensures the contract state is correct before any external call, preventing reentrancy exploits.

🔧 Debug

advanced

Identify the vulnerability in this Solidity withdraw function

Examine the following Solidity function and identify the vulnerability:

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success);
    balances[msg.sender] -= _amount;
}

A The balance is updated after the external call, allowing reentrancy attacks.

B The require statement is missing to check the success of the call.

C The function uses <code>transfer</code> which is unsafe for sending ether.

D The function does not check if _amount is zero.

💡 Hint

Consider the order of operations and what happens if the external call triggers fallback code.

Updating balances after sending ether allows attackers to reenter the function and withdraw multiple times before the balance is decreased.

📝 Syntax

advanced

Which option correctly fixes the reentrancy vulnerability?

Given the vulnerable withdraw function below, which option correctly fixes the reentrancy vulnerability by changing the order of operations?

function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount);
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success);
    balances[msg.sender] -= _amount;
}

A Replace <code>msg.sender.call</code> with <code>msg.sender.transfer</code> without changing order.

B Move <code>balances[msg.sender] -= _amount;</code> before the external call to <code>msg.sender.call</code>.

C Add a mutex lock variable to prevent reentrancy but keep the order same.

D Remove the require statement checking balances.

💡 Hint

Focus on the order of balance update and external call.

Updating the balance before the external call prevents attackers from reentering with an unchanged balance.

🚀 Application

expert

How many times can the attacker recursively call withdraw in this scenario?

An attacker deposits 5 ether into the vulnerable contract below and then calls withdraw(1 ether). The fallback function recursively calls withdraw(1 ether) as long as the balance is sufficient.

contract Vulnerable {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint _amount) public {
        require(balances[msg.sender] >= _amount);
        (bool success, ) = msg.sender.call{value: _amount}("");
        require(success);
        balances[msg.sender] -= _amount;
    }
}

How many times will the attacker be able to withdraw 1 ether recursively before the transaction fails or completes?

A Zero times, the contract reverts immediately.

B 5 times, equal to the initial deposited balance.

C Only once, because the balance check prevents multiple withdrawals.

D More than 5 times, because the balance is updated after sending ether.

💡 Hint

Think about when the balance is decreased relative to the external call and recursive calls.

Because the balance is decreased after the external call, the attacker can recursively withdraw multiple times before the balance is updated, effectively withdrawing more than the deposited amount.