Warum unterscheidet sich die Sicherheit von Smart Contracts von der Sicherheit herkömmlicher Software?

Die Sicherheit von Smart Contracts stellt besondere Anforderungen, weil der Code öffentlich ist, oft direkt Geld verwaltet und nach der Bereitstellung meist nicht mehr geändert werden kann. Ein Fehler in einer Webanwendung lässt sich über Nacht beheben; einen Fehler in einem Smart Contract kann jeder beim Lesen des Codes entdecken und ausnutzen, bevor das Team aufwacht. Ethereum.org schätzt die Verluste durch Fehler in Smart Contracts auf über eine Milliarde Dollar und nennt den DAO-Hack von 2016 als frühes Beispiel.

Stellen Sie sich ein fiktives vierköpfiges Studio vor: Larkspur Labs. Es entwickelt einen einfachen gemeinschaftlichen Spartopf, in den Mitglieder Geld einzahlen und aus dem sie ihren Anteil abheben können. Der Entwickler Kofi hinterlässt vor der Bereitstellung folgende Prüfnotizen: 'withdraw sendet Geld und setzt danach den Kontostand auf 0. setFee ist öffentlich, werde den Zugriff später einschränken. verwende alte Compiler-Version aus Anleitung. Preis des Belohnungstokens wird aus einem einzigen kleinen Handelspool gelesen. Tests: Einzahlung + Auszahlung einmal manuell ausprobiert, funktioniert'. Jede Zeile steht für eine bekannte Schwachstellenklasse.

Was sind die häufigsten Sicherheitslücken in Smart Contracts?

Die häufigsten Schwachstellen von Smart Contracts sind Fehler in der Zugriffskontrolle, Manipulation von Preisorakeln, Logikfehler, fehlende Eingabevalidierung und Wiedereintrittsangriffe. Sie führen die OWASP Smart Contract Top 10 für 2025 an. Ethereum.org behandelt dieselben grundlegenden Schwachstellenklassen.

Wiedereintritt

Ein Smart Contract überweist Geld oder ruft einen anderen Smart Contract auf, bevor er seine eigenen Daten aktualisiert. Ein böswilliger Empfänger ruft ihn erneut auf, solange noch der alte Kontostand angezeigt wird, und hebt nochmals Geld ab. Kofis Auszahlungsfunktion, die zuerst auszahlt und erst danach den Kontostand auf null setzt, ist ein klassisches Beispiel. Die übliche Lösung besteht darin, zuerst den Zustand zu aktualisieren und erst zuletzt mit anderen Smart Contracts zu interagieren. Dieses Muster wird oft als Prüfen, Zustandsänderungen, Interaktionen bezeichnet.

Zugriffskontrolle

Sensible Funktionen, die jeder aufrufen kann. Kofis öffentliche Funktion setFee erlaubt es beliebigen Fremden, die Gebühr zu ändern. Ethereum.org beschreibt Ansätze wie eine Eigentümerrolle, rollenbasierten Zugriff und die Freigabe durch mehrere Signaturen.

Ganzzahlüberlauf und -unterlauf

Ein arithmetischer Überlauf, bei dem die Berechnung nach Überschreiten einer Grenze am anderen Ende des Wertebereichs weiterläuft, sodass aus einem Kontostand unter null eine riesige Zahl wird. Ethereum.org weist darauf hin, dass Solidity 0.8.0 und spätere Versionen dies standardmäßig verhindern, während älterer Code ausdrückliche Prüfungen benötigt. Deshalb spielt Kofis alter Compiler eine Rolle.

Manipulation von Orakeln

Einen Preis aus einem einzigen Markt mit geringer Liquidität auslesen, den ein Angreifer manipulieren kann, oft mithilfe eines Blitzkredits, der innerhalb einer einzigen Transaktion aufgenommen und zurückgezahlt wird. Robuste Systeme verwenden dezentrale Orakel oder zeitlich gemittelte Preise.

Logik- und Validierungsfehler

Regeln, die nicht der vorgesehenen Ausgestaltung entsprechen, oder Eingaben, die nie geprüft werden, etwa ein Nullbetrag oder eine unerwartete Adresse.

Wie testen und prüfen Teams Smart Contracts?

Teams prüfen und testen Smart Contracts auf mehreren Ebenen, weil keine einzelne Methode alles erfasst: automatisierte Tests, Analysewerkzeuge, Bereitstellung in einem Testnetzwerk, unabhängige Prüfung und bei Verträgen, die erhebliche Vermögenswerte verwalten, ein externes Audit sowie ein Prämienprogramm für gemeldete Sicherheitslücken.

1. Komponenten- und eigenschaftsbasierte Tests

Schreiben Sie Tests für jede Funktion, einschließlich bösartiger Fälle, etwa eines Empfängers, der einen Rückaufruf ausführt. Beim Fuzzing werden automatisch Tausende zufälliger Eingaben ausprobiert.

2. Statische Analyse

Ethereum.org nennt Werkzeuge wie Slither, Mythril und Aderyn, die Code auf bekannte riskante Muster untersuchen.

3. Testen Sie Netzwerke

Stellen Sie den Code zuerst in einem öffentlichen Testnetz bereit, bevor Sie ihn im Hauptnetz bereitstellen. Ethereum.org empfiehlt Sepolia für die Entwicklung von Anwendungen und Smart Contracts; Ether im Testnetz soll keinen realen Wert haben, sodass Fehler nichts kosten.

4. Prüfung durch Fachkollegen und geprüfte Bibliotheken

Verwenden Sie Versionskontrolle, unabhängige Prüfer bei jeder Änderung und gründlich geprüfte Bibliotheken wie OpenZeppelin Contracts, statt die Zugriffskontrolle von Grund auf selbst zu programmieren.

5. Prüfung, Prämien für gemeldete Sicherheitslücken und Überwachung

Unabhängige Prüfungen sorgen für zusätzliche Kontrolle, finden aber, wie ethereum.org anmerkt, nicht jeden Fehler. Prämien für gefundene Sicherheitslücken, Notfall-Pausenfunktionen und die Überwachung von Ereignissen decken verbleibende Risiken ab.

Wie sieht eine schwache und eine verbesserte Sicherheitsprüfung aus?

Schwache Prüfung: „Ein- und Auszahlung manuell getestet, funktioniert einwandfrei, bereit zur Bereitstellung.“ Ein Test des vorgesehenen Ablaufs zeigt, dass der Vertrag für ehrliche Nutzer funktioniert – und genau das sind Angreifer nicht.

Verbesserte Prüfung: Wiedereintritt: withdraw setzt den Kontostand jetzt vor dem Senden auf null. Ein Test versucht mit einem bösartigen Empfängervertrag, die Funktion erneut aufzurufen. Zugriffskontrolle: setFee ist auf eine Eigentümerrolle aus einer geprüften Bibliothek beschränkt. Ein Test prüft, dass der Aufruf durch eine unbefugte Person scheitert. Compiler: auf eine aktuelle 0.8-Version aktualisiert, damit Überlaufprüfungen aktiv sind. Orakel: Der Preis aus einem einzelnen Liquiditätspool wurde durch eine dezentrale Preisquelle ersetzt, ergänzt um eine Plausibilitätsgrenze für plötzliche Bewegungen. Tests: Komponententests, ein Fuzzing-Durchlauf und eine statische Analyse mit Erläuterung jedes Befunds, anschließend zwei Wochen auf Sepolia, in denen ein Kollege versucht, Fehler auszulösen. Eine externe Prüfung ist gebucht, bevor echte Gelder angenommen werden.

Was sind häufige Fehler bei der Sicherheit von Smart Contracts?

Der häufigste Fehler ist, nur den vorgesehenen Normalfall zu testen, als wären alle Aufrufer ehrlich. Weitere Fehler: Verwaltungsfunktionen zunächst offen lassen, um sie später einzuschränken, Beispielcode aus einer Anleitung mit einem veralteten Compiler übernehmen, einer einzigen Preisquelle vertrauen, eine Prüfung als Garantie behandeln, die Testnetzphase überspringen und ohne Plan für eine Unterbrechung oder Aktualisierung in Betrieb gehen.

Wo ist diese Lektion bei Tosheo.ai eingeordnet?

Dies ist eine Programmierlektion in der Kategorie Blockchain und im Blockchain-Kurs. Diese kostenlose Seite erklärt jeden Schritt in Textform. Die vollständige Praxisversion, in der Sie echten Vertragscode prüfen und korrigieren sowie Tests in einem Testnetzwerk ausführen, ist nach der Registrierung im optionalen Programmierpfad verfügbar. Beginnen Sie mit der Einführung in intelligente Verträge, wenn Ihnen die Grundlagen noch neu sind. Tosheo.ai ist weder ein Vollzeit-Intensivkurs noch eine berufliche Qualifikation für Sicherheitsprüfungen. Nichts hier ist Anlageberatung. Verträge, die reale Werte verwalten, benötigen eine fachkundige Sicherheitsprüfung.

Quellen und Geltungsbereich

ethereum.org, Sicherheit intelligenter Verträge (geprüft am 19 October 2026) ↗

OWASP: Die 10 wichtigsten Risiken bei intelligenten Verträgen, 2025 (geprüft am 19 October 2026) ↗

ethereum.org, Netzwerke und Testnetzwerke (geprüft am 19 October 2026) ↗