Common vulnerability patterns in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - Common vulnerability patterns

Start: Smart Contract Deployment

↓

User Interaction with Contract

↓

Check for Vulnerabilities

↓

Reentrancy

↓

Funds Drained

↓

Security Patch

↓

End

This flow shows how a smart contract is deployed, users interact, vulnerabilities may occur, and how they lead to problems before a patch fixes them.

Execution Sample

Blockchain / Solidity

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

This contract allows users to withdraw funds but is vulnerable to reentrancy attacks because it sends funds before updating balances.

Execution Table

Step	Action	Condition/Evaluation	State Change	Result/Output
1	User calls withdraw(10)	balances[user] >= 10 is True	No change yet	Proceed to send funds
2	Contract sends 10 ether to user	Call to user succeeds	Funds sent but balances not updated	User receives 10 ether
3	User's fallback calls withdraw again (reentrancy)	balances[user] still >= 10 is True	No balance deducted yet	Funds sent again
4	Balances updated after calls	balances[user] -= 10	Balance reduced by 10 only once	User drained more funds than allowed
5	Attack ends when balance < amount	balances[user] < 10	No more withdrawals allowed	Contract drained
6	Security patch: update balance before sending	balances[user] -= amount before call	Balance updated early	Reentrancy prevented

💡 Execution stops when user's balance is insufficient or attack is prevented by patch.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
balances[user]	100	100	100	100	90	90
funds sent	0	0	10	20	20	20
call success	N/A	N/A	True	True	True	True

Key Moments - 3 Insights

Why does the contract send funds before updating the balance cause a problem?

Because in step 2 and 3 of the execution_table, the contract sends funds before reducing the balance, allowing the user to call withdraw multiple times and drain funds.

What stops the attack eventually?

In step 5, the user's balance becomes less than the withdrawal amount, so the require condition fails and no more funds are sent.

How does updating the balance before sending funds prevent reentrancy?

As shown in step 6, updating the balance early means the condition fails on reentrant calls, stopping multiple withdrawals.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, what allows the user to withdraw funds again?

A The balance is updated before sending funds

B The balance is not updated before sending funds

C The call to user fails

D The require condition fails

💡 Hint

Check the 'State Change' column at step 3 showing balance not updated yet.

At which step does the contract finally reduce the user's balance?

A Step 2

B Step 3

C Step 4

D Step 6

💡 Hint

Look at the 'State Change' column where balances[user] -= 10 happens.

If the contract updated balance before sending funds, which step would change?

A Step 2 would update balance before sending

B Step 3 would allow reentrancy

C Step 5 would never be reached

D Step 4 would send more funds

💡 Hint

Refer to step 6 in execution_table describing the security patch.

Concept Snapshot

Common vulnerability patterns in blockchain contracts:
- Reentrancy: Sending funds before updating state allows repeated calls.
- Integer Overflow: Arithmetic errors cause wrong balances.
- Unchecked Calls: Ignoring call success leads to silent failures.
Always update state before external calls and check all conditions.

Full Transcript

This visual execution shows a common vulnerability pattern called reentrancy in blockchain smart contracts. The contract lets users withdraw funds but sends money before updating their balance. This allows a user to call withdraw repeatedly before the balance is reduced, draining more funds than allowed. The execution table traces each step: user calls withdraw, funds are sent, fallback triggers another withdraw, and balance updates happen too late. The variable tracker shows balances and funds sent at each step. Key moments explain why sending funds before updating balance is dangerous and how updating balance first stops the attack. The quiz tests understanding of these steps. The snapshot summarizes key vulnerability patterns and best practices to avoid them.

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