Common vulnerability patterns in Blockchain / Solidity - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to prevent reentrancy by using a mutex lock.

Blockchain / Solidity

bool locked = false;

function withdraw(uint amount) public {
    require(![1], "Reentrant call detected");
    locked = true;
    // send funds
    locked = false;
}

Drag options to blanks, or click blank then click option'

Alocked

Btrue

Camount

Dmsg.sender

Attempts:

3 left

💡 Hint

Common Mistakes

Using a constant true value in the require statement.

Checking the amount or sender instead of the lock variable.

The variable locked is used as a mutex to prevent reentrancy. The require checks that locked is false before proceeding.

2fill in blank

medium

Complete the code to check for integer overflow before addition.

Blockchain / Solidity

function add(uint a, uint b) public pure returns (uint) {
    uint c = a + b;
    require(c [1] a, "Overflow detected");
    return c;
}

Drag options to blanks, or click blank then click option'

A<

B!=

C==

D>=

Attempts:

3 left

💡 Hint

Common Mistakes

Using < which would allow overflow.

Using equality which does not detect overflow.

The sum c should be greater than or equal to a to ensure no overflow occurred.

3fill in blank

hard

Fix the error in the access control modifier to restrict function calls to the owner only.

Blockchain / Solidity

address owner;

modifier onlyOwner() {
    require(msg.sender [1] owner, "Not owner");
    _;
}

Drag options to blanks, or click blank then click option'

A!=

B==

C>

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using inequality operator which blocks the owner.

Using greater or less than which is invalid for addresses.

The modifier should check that the caller is exactly the owner using ==.

4fill in blank

hard

Fill both blanks to safely update a mapping after checking conditions.

Blockchain / Solidity

mapping(address => uint) balances;

function updateBalance(address user, uint amount) public {
    require(balances[user] [1] 0, "No balance");
    balances[user] [2] amount;
}

Drag options to blanks, or click blank then click option'

A>

B=

C<

D+=

Attempts:

3 left

💡 Hint

Common Mistakes

Using less than in the require which allows zero balances.

Using += which adds instead of replacing the balance.

The require checks that the user has a positive balance using >. Then the balance is set to the new amount using =.

5fill in blank

hard

Fill all three blanks to implement a safe withdrawal function avoiding reentrancy and updating state correctly.

Blockchain / Solidity

bool locked = false;

function safeWithdraw(uint amount) public {
    require(![1], "Reentrant call");
    locked = true;
    require(balances[msg.sender] [2] amount, "Insufficient balance");
    balances[msg.sender] [3] balances[msg.sender] - amount;
    // send funds
    locked = false;
}

Drag options to blanks, or click blank then click option'

Alocked

B>=

C=

D-=

Attempts:

3 left

💡 Hint

Common Mistakes

Using -= which may cause underflow in older Solidity versions.

Not checking balance before withdrawal.

Not using the lock variable correctly.

The locked variable prevents reentrancy. The balance is checked to be at least the amount with >=. The balance is updated by assigning the new value with =.

Practice

1. Which of the following is a common vulnerability in blockchain smart contracts that allows attackers to repeatedly call a function before the first call finishes?

easy

A. Phishing attack

B. Integer overflow

C. Timestamp dependency

D. Reentrancy attack

Solution

1. Step 1: Understand reentrancy attack

   Reentrancy happens when a contract calls another contract and the called contract calls back before the first call finishes.

2. Step 2: Identify the vulnerability type

   This allows attackers to exploit the contract by repeatedly calling a function, draining funds.

3. Final Answer:

   Reentrancy attack -> Option D

4. Quick Check:

   Repeated calls before completion = Reentrancy attack [OK]

Hint: Repeated calls before finish? It's reentrancy [OK]

Common Mistakes:

• Confusing integer overflow with repeated calls
• Thinking timestamp dependency allows repeated calls
• Mixing phishing attack with smart contract vulnerabilities

2. Which of the following Solidity code snippets correctly prevents integer overflow using Solidity 0.8+ built-in checks?

easy

A. uint256 x = a + b; // no extra check needed

B. uint256 x = SafeMath.add(a, b);

C. uint256 x = a + b; require(x >= a);

D. uint256 x = a - b; // prevents overflow

Solution

1. Step 1: Recall Solidity 0.8+ overflow behavior

   From Solidity 0.8, arithmetic operations revert on overflow automatically.

2. Step 2: Identify correct prevention method

   So, just using uint256 x = a + b; is safe without extra checks or libraries.

3. Final Answer:

   uint256 x = a + b; // no extra check needed -> Option A

4. Quick Check:

   Solidity 0.8+ auto checks overflow = uint256 x = a + b; // no extra check needed [OK]

Hint: Solidity 0.8+ auto checks overflow, no SafeMath needed [OK]

Common Mistakes:

• Using SafeMath in Solidity 0.8+ unnecessarily
• Adding manual require checks that are redundant
• Confusing subtraction with addition overflow

3. Consider this Solidity function snippet:

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

What is the main vulnerability in this code?

medium

A. Integer overflow in balances update

B. Reentrancy attack due to external call before state update

C. Timestamp dependency in withdrawal timing

D. Unchecked call return value

Solution

1. Step 1: Analyze call order in function

   The external call to msg.sender.call happens before updating balances[msg.sender].

2. Step 2: Identify vulnerability type

   This allows reentrancy: attacker can call withdraw again before balance is reduced.

3. Final Answer:

   Reentrancy attack due to external call before state update -> Option B

4. Quick Check:

   External call before balance update = Reentrancy risk [OK]

Hint: External call before state update? Watch for reentrancy [OK]

Common Mistakes:

• Thinking integer overflow is the issue here
• Ignoring call return value is not the main problem
• Confusing timestamp dependency with this pattern

4. This Solidity code snippet is intended to prevent reentrancy. What is the bug?

mapping(address => uint) public balances;

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

medium

A. Balance is set to zero after sending funds, causing loss of remaining balance for partial withdrawals

B. No require check on call success

C. Balances mapping is not initialized

D. Function lacks payable modifier

Solution

1. Step 1: Check balance update order

   Balance is reduced before sending funds (good for reentrancy prevention), but then reset to zero after sending.

2. Step 2: Identify bug impact

   For partial withdrawals (e.g., balance=20, amount=10), after -=10 and send 10, setting to 0 discards the remaining 10 without sending it, stealing user funds.

3. Final Answer:

   Balance is set to zero after sending funds, causing loss of remaining balance for partial withdrawals -> Option A

4. Quick Check:

   Post-call balance=0 after partial -= = remaining balance theft [OK]

Hint: Extra balance=0 after partial -= and send? Steals remainder [OK]

Common Mistakes:

• Ignoring that balance reset happens after external call
• Thinking missing payable modifier causes this bug
• Assuming call success check is missing

5. You want to write a Solidity function that safely transfers tokens and prevents both reentrancy and integer overflow. Which approach is best?

hard

A. Call external contracts first, then update balances with SafeMath

B. Use timestamp checks to limit withdrawals and SafeMath for math

C. Update state variables before external calls and use Solidity 0.8+ arithmetic

D. Avoid updating balances and rely on external contract trust

Solution

1. Step 1: Prevent reentrancy by state update order

   Update all internal state variables before making any external calls to avoid reentrancy.

2. Step 2: Prevent integer overflow using Solidity 0.8+

   Use Solidity 0.8+ built-in overflow checks instead of external libraries.

3. Final Answer:

   Update state variables before external calls and use Solidity 0.8+ arithmetic -> Option C

4. Quick Check:

   State update first + Solidity 0.8+ overflow checks = Safe transfer [OK]

Hint: Update state before calls; Solidity 0.8+ handles overflow [OK]

Common Mistakes:

• Calling external contracts before state update
• Relying on timestamp checks for safety
• Ignoring overflow checks in older Solidity versions