Wie prüft man einen Smart Contract? (Sicherheitsgrundlagen)

Schwachstellen bei Smart Contracts verstehen

1. Wiedereintrittsangriffe treten auf, wenn ein böswilliger Vertrag wiederholt auf den anfälligen Vertrag zurückgreift, bevor Zustandsänderungen abgeschlossen sind, wodurch unerwartet Gelder abgezogen werden.

2. Ganzzahlüberläufe und -unterläufe treten auf, wenn arithmetische Operationen die Maximal- oder Minimalwerte von uint256 überschreiten, was zu falschen Salden oder logischen Umgehungen führt.

3. Ungeprüfte externe Aufrufe können zu stillen Fehlern führen, wenn die Rückgabewerte nicht validiert werden, sodass die Ausführung trotz fehlgeschlagener Übertragungen oder Funktionsaufrufe fortgesetzt werden kann.

4. Eine unsachgemäße Zugriffskontrolle ermöglicht es nicht autorisierten Benutzern, privilegierte Funktionen wie Upgrades nur für Besitzer oder Token-Minting aufzurufen.

5. Front-Running wird möglich, wenn kritische Zustandsübergänge auf einer vorhersehbaren Transaktionsreihenfolge beruhen und sensible Vorgänge wie Auktionen oder Flash-Darlehensarbitrage offengelegt werden.

Statische Analysetools und ihre Rolle

1. Slither analysiert den Solidity-Quellcode auf gängige Anti-Patterns und Schwachstellen, ohne den Vertrag auszuführen, und liefert so eine schnelle und skalierbare Erkennung.

2. MythX lässt sich in IDEs und CI/CD-Pipelines integrieren, um symbolische Ausführung und Fuzzing-basierte Analysen durchzuführen und tiefere Logikfehler zu identifizieren.

3. Solhint setzt Codierungsstandards und Best Practices durch, indem es inkonsistente Sichtbarkeitsspezifizierer, fehlende Require-Anweisungen und unsichere Low-Level-Aufrufe kennzeichnet.

4. Echidna von Crytic führt eigenschaftsbasierte Tests mit benutzerdefinierten, in Solidity geschriebenen Behauptungen durch und überprüft Invarianten über Tausende von generierten Eingaben hinweg.

5. Die parallele Verwendung mehrerer statischer Analysegeräte erhöht die Abdeckung erheblich – kein einzelnes Tool erkennt alle Fehlerklassen.

Grundlagen der manuellen Codeüberprüfung

1. Verfolgen Sie alle externen Aufrufe und überprüfen Sie, ob sie nach Zustandsaktualisierungen erfolgen, insbesondere bei Auszahlungs- oder Übertragungsfunktionen.

2. Stellen Sie sicher, dass alle vom Benutzer bereitgestellten Eingaben die Anweisungen „require“ oder „revert“ durchlaufen, bevor sie sich auf die Speicherung auswirken oder Ereignisse ausgeben.

3. Untersuchen Sie Fallback- und Empfangsfunktionen auf unbeabsichtigtes Verhalten, insbesondere bei der Verarbeitung von ETH-Transfers neben komplexer Logik.

4. Suchen Sie nach fest codierten Adressen, magischen Zahlen oder nicht versionierten Bibliothekslinks, die die Reproduzierbarkeit beeinträchtigen oder versteckte Abhängigkeiten einführen könnten.

5. Jeder Modifikator muss auf Wiedereintrittssicherheit, Nebenwirkungen und Komposibilität mit anderen Modifikatoren geprüft werden.

Testmethoden über Einheitenprüfungen hinaus

1. Integrationstests simulieren Interaktionen zwischen mehreren bereitgestellten Verträgen, um Schnittstelleninkongruenzen und unerwartete Gasverbrauchsmuster aufzudecken.

2. Fuzz-Tests fügen zufällige Eingaben in öffentliche Funktionen ein, um Randfallverhalten auszulösen, das bei Komponententests häufig übersehen wird.

3. Eigenschaftsbasierte Tests definieren Invarianten auf hoher Ebene – wie „Das Gesamtangebot nimmt nie ab“ oder „Salden können nicht negativ werden“ – und validieren sie in verschiedenen Szenarien.

4. Testnetze wie Sepolia und Arbitrum Goerli bieten realistische Umgebungen, in denen reale Gasdynamik und Netzwerküberlastung beobachtet werden können.

5. Zeitabhängige Logik muss unter simulierter Block-Zeitstempelmanipulation getestet werden, um die Korrektheit bei Verzögerungen oder zukünftiger Planung sicherzustellen.

Häufig gestellte Fragen

F: Kann ich mich bei der intelligenten Vertragsprüfung ausschließlich auf automatisierte Tools verlassen? A: Nein. Automatisierte Tools erkennen bekannte Muster, können jedoch nicht die Korrektheit der Geschäftslogik, wirtschaftliche Anreize oder neuartige Angriffsvektoren beurteilen, die menschliche Intuition und Domänenwissen erfordern.

F: Was bedeutet „vertrauenswürdiges Setup“ im Zusammenhang mit Zero-Knowledge-Proof-Verträgen? A: Es bezieht sich auf die anfängliche Generierung kryptografischer Parameter, die für die zk-SNARK-Verifizierung erforderlich sind; Wenn es kompromittiert wird, bricht es die Zuverlässigkeitsgarantien und ermöglicht es gefälschten Beweisen, die Validierung zu bestehen.

F: Warum sollte ich die Verwendung von tx.origin für Autorisierungsprüfungen vermeiden? A: Da tx.origin den ursprünglichen EOA zurückgibt, der die Transaktionskette initiiert hat, ist es anfällig für Phishing über Zwischenverträge, die Anrufe unter Beibehaltung des Ursprungs weiterleiten.

F: Wie unterscheiden sich Schwachstellen bei Delegatecalls von Schwachstellen bei regulären Anrufen? A: Delegatecall führt Code im Kontext des aufrufenden Vertrags aus, was bedeutet, dass Nichtübereinstimmungen im Speicherlayout oder nicht initialisierte Variablen im Ziel den Status des Aufrufers direkt beschädigen können.