Blockchain Smart Contracts with Solidity · Lektion

Häufige Schwachstellen (Reentrancy usw.)

Verstehen und entschärfen Sie verbreitete Schwachstellen von Smart Contracts wie Reentrancy, Integer-Über- und -Unterläufe sowie Front-Running-Angriffe.

Lektion 1 von 412 Schritte

Häufige Schwachstellen (Reentrancy usw.) ist eine kostenlose Blockchain Smart Contracts with Solidity-Lektion auf CoddyKit. Dies ist Lektion 1 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Blockchain Smart Contracts with Solidity-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Blockchain Smart Contracts with Solidity-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

Smart Contract Security: Overview

Welcome to this crucial lesson on smart contract security! Unlike traditional software, bugs in smart contracts can lead to irreversible loss of funds.

Because contracts on the blockchain are often immutable, fixing vulnerabilities after deployment is incredibly difficult, if not impossible. Security must be a top priority from day one.

Understanding Reentrancy Attacks

Reentrancy is a critical vulnerability where an external call to an untrusted contract can 're-enter' the original contract before the first function call has completed its execution.

This allows the attacker to repeatedly drain funds or manipulate state by calling the vulnerable function multiple times.

Reentrancy: A Vulnerable Example

Consider this simplified withdrawal contract. Can you spot the potential issue?

The state (balances[msg.sender]) is updated *after* the external call to msg.sender.call. This delay creates a window for attack.

pragma solidity ^0.8.0;

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

  constructor() payable {
    // Fund contract for demo purposes
  }

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

  function withdraw(uint _amount) public {
    require(balances[msg.sender] >= _amount, "Insufficient balance");

    // External call FIRST, state update LATER
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Transfer failed");

    balances[msg.sender] -= _amount; // This line is vulnerable!
  }

  function getBalance() public view returns (uint) {
    return address(this).balance;
  }
}

The Reentrancy Attack Flow

Here's how an attacker exploits the previous contract:

  • 1. Deposit: Attacker deposits funds into VulnerableWithdraw.
  • 2. Withdraw: Attacker calls withdraw(amount).
  • 3. Re-enter: When msg.sender.call transfers Ether to the attacker, their malicious fallback function is triggered.
  • 4. Repeat: The fallback function immediately calls withdraw(amount) again, before the original call updates the balance. This repeats until funds are drained.

Mitigating Reentrancy: The Fix

The most effective way to prevent reentrancy is to follow the Checks-Effects-Interactions (CEI) pattern:

  • 1. Checks: Verify all conditions (e.g., require statements).
  • 2. Effects: Update all state variables (e.g., balances[msg.sender] -= _amount).
  • 3. Interactions: Make external calls (e.g., msg.sender.call).

This ensures state is updated *before* any untrusted external code can execute.

Reentrancy: The Fixed Contract

Here's the corrected version of the withdrawal contract, applying the CEI pattern. Notice the order of operations.

Now, the balance is decremented *before* the external call, closing the reentrancy window.

pragma solidity ^0.8.0;

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

  constructor() payable {
    // Fund contract for demo purposes
  }

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

  function withdraw(uint _amount) public {
    // 1. Checks
    require(balances[msg.sender] >= _amount, "Insufficient balance");

    // 2. Effects: Update state BEFORE external call
    balances[msg.sender] -= _amount;

    // 3. Interactions: Make external call LAST
    (bool success, ) = msg.sender.call{value: _amount}("");
    require(success, "Transfer failed");
  }

  function getBalance() public view returns (uint) {
    return address(this).balance;
  }
}

Integer Overflows & Underflows

Integer overflows occur when an arithmetic operation results in a value larger than the maximum that the variable type can hold. It 'wraps around' to its minimum value.

Integer underflows are the opposite: when a result is smaller than the minimum value, wrapping around to the maximum.

For example, a uint8 can hold values from 0 to 255. If it's 255 and you add 1, it becomes 0 (overflow). If it's 0 and you subtract 1, it becomes 255 (underflow).

Overflow/Underflow Example

Prior to Solidity 0.8.0, these operations would silently wrap around. Since Solidity 0.8.0, arithmetic operations default to checking for overflows/underflows and will revert if one occurs.

However, understanding the concept is vital, especially when working with older codebases or using unchecked blocks for gas optimization.

pragma solidity ^0.8.0;

contract MathVulnerabilities {
  uint8 public smallNumber = 255; // Max for uint8

  function triggerOverflow() public {
    // In Solidity 0.8.0+, this transaction will revert.
    // In older versions, smallNumber would become 0.
    smallNumber = smallNumber + 1;
  }

  function triggerUnderflow() public {
    smallNumber = 0; // Reset for demo
    // In Solidity 0.8.0+, this transaction will revert.
    // In older versions, smallNumber would become 255.
    smallNumber = smallNumber - 1;
  }
}

Front-Running Attacks

Front-running is an attack where a malicious actor observes a pending transaction and submits their own transaction with a higher gas fee to have it executed first.

This is common in DeFi (Decentralized Finance) where transactions like large swaps or liquidations can be anticipated and exploited for profit.

Mitigating Front-Running

Preventing front-running is challenging due to the public nature of the mempool (pending transaction pool). However, some strategies exist:

  • Commit-Reveal Schemes: Users submit a hashed version of their intent (commit), then later reveal the actual data.
  • Batching: Grouping transactions together to reduce individual transaction visibility.
  • Decentralized Sequencers/L2s: Using solutions that offer more private or controlled transaction ordering.
  • Slippage Control: Users setting maximum acceptable price slippage for swaps.

Vulnerability Check

You've learned about three major smart contract vulnerabilities. Let's test your understanding!

Recap: Security First

In this lesson, we explored critical smart contract vulnerabilities: reentrancy, integer overflows/underflows, and front-running.

  • We saw how reentrancy exploits external calls and how the Checks-Effects-Interactions pattern provides a robust defense.
  • We understood how integer arithmetic can lead to unexpected values and the importance of compiler checks (Solidity 0.8.0+).
  • Finally, we discussed front-running and methods like commit-reveal to mitigate it.

Always prioritize security in your smart contract development!

Kostenlos starten

Lerne Blockchain Smart Contracts with Solidity mit einem KI-Tutor — kostenlos

Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.

Kurse
12
Lektionen
48

Häufig gestellte Fragen

Ist die Lektion „Häufige Schwachstellen (Reentrancy usw.)“ kostenlos?

Ja — der vollständige Text von „Häufige Schwachstellen (Reentrancy usw.)“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Blockchain Smart Contracts with Solidity-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Blockchain Smart Contracts with Solidity-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Häufige Schwachstellen (Reentrancy usw.)“?

Verstehen und entschärfen Sie verbreitete Schwachstellen von Smart Contracts wie Reentrancy, Integer-Über- und -Unterläufe sowie Front-Running-Angriffe. Du übst Blockchain Smart Contracts with Solidity mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Blockchain Smart Contracts with Solidity zu starten?

Keine Vorkenntnisse erforderlich. Blockchain Smart Contracts with Solidity auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 1 von 4.

Wie lange dauert die Lektion „Häufige Schwachstellen (Reentrancy usw.)“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Blockchain Smart Contracts with Solidity-Lektion Code schreiben und ausführen?

Ja. Jede Blockchain Smart Contracts with Solidity-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Häufige Schwachstellen (Reentrancy usw.)
  2. Muster für Zugriffskontrolle
  3. Sichere Programmierung mit SafeMath
  4. Auditing, Testing und Bug Bounties
← Zurück zu Blockchain Smart Contracts with Solidity