Gibt es ein Tool, eine Checkliste mit Methoden zur Überprüfung der Smart Contract-Sicherheit?
ZB für jede Funktion, die Sie überprüfen
Gibt es eine Wiedereintrittsmöglichkeit und wie verhält es sich beim Wiedereintritt?
Wie es sich verhält, wenn den Schleifen das Gas ausgeht
Wie es sich verhält, wenn das Stapellimit erreicht ist
... usw.
Wenn kein solches Tool verfügbar ist, gibt es eine gute Quelle oder Liste für alle bekannten Fehlermodi der Smart Contract-Sicherheit von Ethereum?
Dies ist die Antwort des Community-Wikis (keine Reputation) auf mögliche Angriffe und wie man sich davor schützt. Fühlen Sie sich frei, die Liste zu aktualisieren. Wenn Ihre Vertragsfunktionen Merkmale aufweisen, die den Voraussetzungen entsprechen, bewerten Sie Ihre Funktion sorgfältig anhand der gegebenen Ratschläge.
Dies ist die Liste potenzieller Angriffe oder Fehlpraktiken, die nur diese Angriffe ermöglichen. Weitere Ressourcen für Best Practices für die intelligente Vertragsprogrammierung finden Sie unter dem Link Ressourcen am Ende der Antwort.
Wer die Geschichte nicht lernt, ist dazu verdammt, sie zu wiederholen. Hier ist eine schöne Zusammenfassung bekannter Smart-Contract-Angriffe .
Ein Entwickler schreibt den Code und der andere überprüft ihn. Während der Entwicklung ist es wichtig, mehr als einen Satz Augäpfel zu haben. Probleme sollten während der Entwicklungszeit durch öffentliche Diskussion aufgefangen werden, nicht im Audit.
Versuchen Sie nicht, Smart Contracts wie ERC-20 selbst zu entwickeln. Verwenden Sie stattdessen Open-Source-Bibliotheken, die vorgefertigte und kampferprobte Smart Contracts bereitstellen. Es ist wahrscheinlich, dass Sie einen Fehler machen, wenn Sie etwas von Grund auf neu entwickeln.
Goldstandard-Bibliotheken umfassen, sind aber nicht beschränkt auf
Versuchen Sie mit einer automatisierten Testsuite sicherzustellen, dass Ihr Solidity-Code eine 100-prozentige Codeabdeckung aufweist. Dadurch wird sichergestellt, dass Ihr Code testbar ist. Die automatische Testsuite deckt jede Zeile und jeden Zweig des Smart-Contract-Codes mindestens einmal ab und führt sie aus.
Solidity Unit Tests werden normalerweise in Python ( Brownie , web3.py ) oder JavaScript ( Hardhat , Truffle ) geschrieben .
Tests führen Transaktionen gegen den Smart Contract durch und prüfen, ob der Status der Transaktion nach der Transaktion eingerückt ist. (Anhängig ist der Zustand immer der Buchstabe des Vertrages, aber in diesem Fall würden der Buchstabe und der Einzug nicht übereinstimmen.)
Testen Sie auf positive Fälle und negative Fälle – dh Dinge, die nicht passieren sollten, obwohl Sie wissen, dass sie nicht passieren. Manchmal, wenn der Code lebt und aktualisiert wird, schlüpfen einige neue Probleme durch und sie wurden von den früheren Tests abgefangen – dies wird als Regressionstest bezeichnet.
Audits ohne Tests durchzuführen ist nicht sehr produktiv, da die Tests immer die erste Verteidigungslinie sein sollten, um robusten Code zu schreiben.
Richten Sie Github Continuous Integration ein , das alle Tests für jeden Commit ausführt. Berichte werden automatisch für die Zukunft gespeichert. Dies hilft auch anderen Personen, die Testumgebung zu replizieren und später auszuführen, da aufgrund von Paket-Upgrades die Test-Runner-Tools häufig selbst versagen.
Beispiel
Interne Funktionen sind als solche gekennzeichnet und nur der richtige Autor kann die Funktion aufrufen.
Bitte sehen Sie sich den Parity Wallet Hack erklärt an .
Synonyme: Shallow Stack Attack, Stack Attack
Voraussetzungen: Funktionen verwendet send()odercall()
Aufrufen: Der Angreifer manipuliert den vertragsübergreifenden Aufrufstapel so, dass call() fehlschlägt, indem er den Vertrag mit dem Stapel 1023 aufruft.
Schutz: Überprüfen Sie immer den Rückgabewert von send() und call(). Lieber someAddress.send()vorbeisomeAddress.call.value()
Mehr Info
Synonyme: Race-Condition
Voraussetzungen: Funktionen verwenden send()oder call()für Ether, oder transferFrom()für ERC-20-Token oder send()für ERC-777-Token.
Aufrufen: Der nicht vertrauenswürdige aufgerufene Vertrag ruft dieselbe Funktion zurück und hat sie in einem unerwarteten Zustand. So wurde TheDAO gehackt. Der Angriff kann über mehrere Funktionen verkettet werden (Cross Function Race Condition).
Schutz: Schützen Sie Ihre Funktionen mit Wiedereintrittssicherungen . Verwenden Sie die Check-Effect-Interact- Reihenfolge von Aktionen in Ihren Funktionen, die alles aufrufen, was an den Smartcontract zurückgespiegelt werden könnte.
Verwenden Sie dieses Muster, um den Schaden eines potenziellen Wiedereintrittsangriffs zu minimieren.
Zuerst prüfen , Dinge wie ausführenrequire()
Dann Effekt , Zähler aktualisieren, wiebalance[address] -= 10
Führen Sie zuletzt alles aus, was Interactsend() ist und Code in anderen Verträgen über , call(), transferFrom()und andere ausführt .
Mehr Info
Voraussetzungen: Funktionen verwendet send()oder call()mit throw nach Fehler
Aufruf: Der Angreifer manipuliert den Vertragszustand so, dass er send()immer fehlschlägt (z. B. Rückerstattung)
Schutz: Ziehen Sie das Zahlungssystem vorsend()
Mehr Info
Voraussetzungen: Ihr Smart Contract liest Kursdaten und handelt darauf basierend
Aufruf: Schlichtungsmöglichkeiten und unsichere Preis-Feeds sind möglicherweise keine Exploits per se, setzen die Benutzer aber dennoch dem Verlust von Geldern aus, der sonst hätte vermieden werden können. Bei einem wirtschaftlichen Angriff nutzt der Angreifer die Gelegenheit, gegen jemanden gewinnbringend zu handeln, normalerweise basierend auf Preisunterschieden eines Tokens.
Schutz: Verlassen Sie sich nicht auf den Spotpreis der Börsen oder automatisierte Market-Making Smart Contracts. Alle Preise, einschließlich Stablecoin-Preise, unterliegen Manipulationen.
Beliebte automatisierte Market Maker und Smart Contracts bieten sichere Funktionen, um den Preis in verschiedenen Situationen zu berechnen.
Mehr Info
Voraussetzungen: Nutzung eines externen Vertrags als Bibliothek und Bezug über die Registry.
Aufruf: Rufen Sie eine andere Vertragsfunktion über eine Vertragsregistrierung auf (siehe librarySchlüsselwort in Solidity).
Schutz: Stellen Sie sicher, dass keine dynamischen Teile in zukünftigen Versionen ausgetauscht werden können.
Voraussetzungen: Die Funktion akzeptiert ein uint-Argument, das in Mathematik verwendet wird
Aufruf: Senden einer sehr großen oder sehr negativen Ganzzahl, wodurch die Summenberechnung überläuft
Schutz: Überprüfen Sie immer die Reihenfolge der Werte, wenn Sie mathematische Operationen durchführen. ZB https://github.com/Firstbloodio/token/blob/master/smart_contract/FirstBloodToken.sol
Mehr Info
Voraussetzungen: Zahlungslogik erfordert Divisionsoperator /
Aufruf: Programmierfehler
Schutz: Beachten Sie, dass Divisionen immer abgerundet werden
Sonstiges: Zuordnung zu kleiner int für Arrays
Voraussetzungen: Beliebige Schleife, Arrays oder Strings im Speicher kopieren. Eine for-Schleife, bei der Vertragsbenutzer die Länge der Schleife erhöhen können. Betrachten Sie Abstimmungsszenarioschleifen.
Invoking: Der Angreifer erhöht die Array-Länge oder manipuliert das Block-Gas-Limit
Schutz: Verwenden Sie Zahlungssysteme im Pull-Stil. Auf mehrere Transaktionen verteilen send()und msg.gasLimit prüfen.
Voraussetzungen: Ein Solidity-Vertrag mit catch all function() { } zum Empfangen generischer Sends
Aufruf: Programmierfehler
Schutz: 100 % Testabdeckung. Stellen Sie sicher, dass Ihre Fallback-Funktion unter 2300 Gas bleibt. Überprüfen Sie mithilfe der Testsuite, ob alle Zweige der Funktion vorhanden sind. Speichern Sie nichts in der Fallback-Funktion. Rufen Sie keine Verträge auf und senden Sie keine Ether in der Fallback-Funktion.
Mehr Info:
Voraussetzungen: Die Funktion liest den Gesamtsaldo des Vertrags und hat eine davon abhängige Logik
Aufruf: selfdestruct(contractaddress) kann sein Guthaben erzwingen
Schutz: Verlassen Sie sich nicht darauf, dass this.balance innerhalb vorgegebener Grenzen bleibt
Mehr
Synonym: Transaction-Ordering Dependence (TOD)
Voraussetzungen: Ein Bid-Style-Markt wie DAI-Liqudation und Auktionen
Aufruf: Der Angreifer sieht Transaktionen in einem Mempool, bevor sie in der Blockchain abgeschlossen werden. Der Angreifer hat eine privilegierte Verbindung, wie ein Mining-Pool, um seine Transaktion zuerst zu übertragen und den ursprünglichen Wohltäter zu überschreiben.
Schutz: Pre-Commit-Schemata
Mehr
Statische Analysetools, die den Code auf allgemein bekannte Fehler wie Integer Overflows prüfen. Sie können die Absicht des Codes nicht überprüfen, aber sie versuchen, den Code anhand bekannter häufiger Probleme zu analysieren.
Devcon2: Smart Contract Security Referenten: Christoph Jentzsch
Nach einem kurzen Überblick über Smart-Contract-Fehler in der Vergangenheit wird eine Liste wichtiger Erkenntnisse behandelt. Einige Codierungstechniken zur Verhinderung unerwarteten Verhaltens in Smart Contracts werden ebenso behandelt wie einige Bemerkungen zur Governance in dezentralen Systemen.
Noch einer;
Forscher der National University of Singapore werden in Kürze ein Tool veröffentlichen, mit dem Benutzer von Ethereum feststellen können, ob die von ihnen codierten Smart Contracts gültig sind oder nicht.
eth