Contract-Audits

Warum Smart Contracts auditiert werden

Die meiste Software lässt sich nach dem Fund eines Fehlers reparieren. Ein Smart Contract auf einer öffentlichen Chain meist nicht. ethereum.org hält fest, dass bereitgestellter Contract-Code meist nicht geändert werden kann, um Sicherheitslücken zu schließen, und schätzt, dass der durch Sicherheitsmängel in Smart Contracts gestohlene oder verlorene Wert leicht über 1 Milliarde US-Dollar liegt ^[1]. Der Code hält oft direkt Geld, ist für jeden öffentlich einsehbar, und ein Angreifer muss nur einen Fehler finden.

Diese Kombination ist der Grund, warum Contracts, die Werte halten, vor dem Deployment von Fachleuten außerhalb des Teams geprüft werden, das sie geschrieben hat. Die Frage ist nicht, ob Sie diese Prüfung brauchen, sondern was sie für Sie leisten kann und was nicht.

Was ein Audit tut

Ein Audit ist eine zeitlich begrenzte Prüfung einer bestimmten Version Ihrer Contracts durch Sicherheitsingenieure, die sie nicht geschrieben haben. Ein typischer Auftrag sieht so aus.

1. 01

   Umfang

   Die Prüfer vereinbaren, welche Contracts bei welchem Commit im Umfang sind, und lesen Ihre Dokumentation dazu, was das System tun soll.

2. 02

   Manuelle Prüfung

   Erfahrene Prüfer lesen den Code Zeile für Zeile und suchen nach bekannten Arten von Schwachstellen (Reentrancy, Fehler in der Zugriffskontrolle, ungeprüfte Aufrufe, Rechen- und Rundungsfehler) und nach Logik, die nicht zur erklärten Absicht passt.

3. 03

   Automatisierte Analyse

   Statische Analysewerkzeuge, Fuzzer und manchmal formale Werkzeuge suchen nach Mustern und Randfällen, die ein Mensch übersehen könnte.

4. 04

   Bericht

   Befunde werden nach Schweregrad aufgelistet, von kritisch bis informativ, jeder mit einer Erklärung und einer empfohlenen Korrektur.

5. 05

   Prüfung der Korrekturen

   Ihr Team behebt die Befunde, und die Prüfer kontrollieren die Korrekturen. Der Abschlussbericht nennt, welche Befunde behoben, zur Kenntnis genommen oder offen gelassen wurden.

Die Schwachstellen, die Prüfer am häufigsten finden, in klarer Sprache

• Reentrancy: Der Contract sendet Mittel oder ruft einen anderen Contract auf, bevor er seine eigenen Aufzeichnungen aktualisiert, und der andere Contract ruft zurück, um dieselben Mittel noch einmal zu nehmen.
• Zugriffskontrolle: Eine Funktion, die einem Administrator vorbehalten sein sollte, kann jeder aufrufen, oder eine Administratorrolle lässt sich übernehmen.
• Preismanipulation: Der Contract liest einen Preis aus einer Quelle, die ein Angreifer innerhalb einer Transaktion bewegen kann, etwa einem dünnen Handelspool.
• Rundung und Genauigkeit: kleine Divisionsfehler, die ein Angreifer tausendfach wiederholt oder die einen ersten Einzahler die Anteile aller späteren verzerren lassen.
• Fehler bei Upgrades: ein Proxy, der auf den falschen Code zeigt, Speicher, der zwischen Versionen kollidiert, oder ein Initialisierer, den jeder aufrufen kann.
• Logik, die tut, was der Code sagt, aber nicht, was das Geschäft meinte: eine doppelt erhobene Gebühr, eine Frist, die verkehrt herum geprüft wird.

Was ein Audit nicht abdeckt

ethereum.org ist hier deutlich: Audits finden nicht jeden Fehler und sind vor allem als zusätzliche Prüfrunde gedacht ^[1]. Darüber hinaus beschränkt sich der Umfang der meisten Audits auf den Contract-Code. Viele Verluste kommen von woanders.

Wie Sie einen Auditbericht lesen

1. 01

   Prüfen Sie den Commit

   Der Bericht nennt die genaue geprüfte Version. Stellen Sie sicher, dass sie Byte für Byte mit dem übereinstimmt, was Sie bereitgestellt haben, und dass die bereitgestellten Contracts auf der Chain verifiziert sind.

2. 02

   Lesen Sie Umfang und Annahmen

   Welche Contracts drin waren, welche nicht, und was die Prüfer über Administratoren, Orakel und andere Contracts angenommen haben.

3. 03

   Sehen Sie sich den Status jedes Befunds an

   Behoben, zur Kenntnis genommen oder offen. Ein zur Kenntnis genommener kritischer Befund ist eine geschäftliche Entscheidung, die jemand erklären können sollte.

4. 04

   Lesen Sie auch die informativen Hinweise

   Sie beschreiben oft Designentscheidungen, die die Prüfer riskant, aber nicht falsch fanden, und das ist nützlich für Ihre nächste Version.

Wie Sie sich vorbereiten, damit sich das Audit lohnt

Die Zeit von Prüfern ist knapp und teuer, also ist jede Stunde, die sie damit verbringen, unklaren Code zu verstehen oder Fehler zu finden, die Ihre Tests hätten finden sollen, eine Stunde, die den subtilen Problemen fehlt, für die Sie sie bezahlen. Der Leitfaden von OpenZeppelin zur Audit-Bereitschaft legt dar, was er vor einem Audit erwartet.

• Dokumentation, die Absicht, Designentscheidungen und Annahmen erklärt, von einem README und Architekturnotizen bis zu Kommentaren an jeder Funktion ^[2].
• Tests, die Randfälle und das Zusammenspiel mit anderen Contracts abdecken, mit dem Ziel von mindestens 90 % Codeabdeckung, und Fuzzing, wo es hilft ^[2].
• Sauberer, lesbarer Code, der einem einheitlichen Stil folgt, bewährte Muster wie Checks-Effects-Interactions nutzt und Abhängigkeiten über einen Paketmanager einbindet statt sie zu kopieren ^[2].
• Ausgereifter Code: getestet, dokumentiert und bereit zum Deployment, statt noch in Veränderung ^[2].

Wir ergänzen zwei eigene Gewohnheiten. Der Code wird für die Dauer des Audits bei einem markierten Commit eingefroren, und jede Korrektur danach durchläuft dasselbe Review und dieselbe Testsuite wie die ursprüngliche Arbeit, bevor die Prüfer sie sehen.

Checklisten und Standards und ihre Grenzen

Checklisten helfen beiden Seiten, sich darauf zu einigen, was geprüft wurde. Sie altern aber. Das Register Smart Contract Weakness Classification, lange eine gängige Referenz, gibt an, dass sein Inhalt seit 2020 nicht gründlich aktualisiert wurde und unvollständig sein kann, und verweist stattdessen auf die Spezifikation EEA EthTrust Security Levels und den Smart Contract Security Verification Standard ^[3]. Fragen Sie jeden Prüfer, gegen welchen Standard er prüft, und betrachten Sie eine Befundliste, die nur einem alten Register zugeordnet ist, mit etwas Vorsicht.

Keine Checkliste ersetzt Verständnis. Die Hinweise von Consensys Diligence gehen davon aus, dass die Abwehr bekannter Schwachstellen nicht genügt und die Contract-Entwicklung die Disziplin von Bereichen wie Finanzsystemen braucht: auf Fehler vorbereitet sein und sorgfältig ausrollen ^[4].

Sicherheit über das Audit hinaus

Ein Audit ist eine Momentaufnahme. Der Contract läuft jahrelang, der Code um ihn herum ändert sich, und Angreifer studieren ihn weiter. Die Praktiken unten halten ein System zwischen Audits sicher, und die meisten kosten wenig im Vergleich zu dem, was sie schützen.

• Eigenschaftsbasierte Tests und Fuzzing, die weiterlaufen, während sich der Code ändert, neben Unit-Tests ^[1].
• Formale Verifizierung für die kritischsten Invarianten, wo die Kosten gerechtfertigt sind ^[1].
• Ein Bug-Bounty-Programm nach dem Start, damit Menschen, die ein Problem finden, für die Meldung bezahlt werden statt es auszunutzen ^[1].
• Ein schrittweises Ausrollen: anfangs Grenzen für Einlagen oder Nutzer, die angehoben werden, während sich das System bewährt ^[4].
• Ein Notfall-Pause und ein Upgrade-Weg, wenn das Design sie zulässt, kontrolliert über eine Multisig-Wallet mit Timelock, sodass Änderungen sichtbar sind, bevor sie wirksam werden.
• Überwachung der Aktivität auf der Chain und Warnungen bei ungewöhnlichen Transaktionen, mit einem schriftlichen Plan, wer was tut, wenn etwas schiefgeht.

Zwei Web3-Projekte, nach unserer Preisliste berechnet

Die durchgerechneten Beispiele unten zeigen die Spanne nach unserer heutigen Preisliste, mit den Stunden je Rolle und dem Zahlungsplan. Die Entwicklung umfasst unsere eigenen Tests und interne Sicherheitsprüfung. Ein externes Audit, wo der Contract es rechtfertigt, wird von der Auditfirma angeboten und vorab zum Selbstkostenpreis berechnet, außerhalb der Meilensteine.

Einen Prüfer auswählen

1. 01

   Lesen Sie ihre öffentlichen Berichte

   Seriöse Firmen veröffentlichen frühere Berichte. Achten Sie auf klare Befunde, vernünftige Schweregrade und ehrliche Abschnitte zum Umfang.

2. 02

   Fragen Sie, wer die Arbeit macht

   Namen und Erfahrung der Prüfer in Ihrem Auftrag zählen mehr als die Marke.

3. 03

   Vereinbaren Sie den Umfang schriftlich

   Welche Contracts, welcher Commit, welche Annahmen und ob eine Prüfung der Korrekturen enthalten ist.

4. 04

   Passen Sie den Aufwand dem Risiko an

   Ein Contract, der erhebliche Werte halten wird, kann mehr als ein unabhängiges Audit rechtfertigen. Ein einfacher Contract auf auditierten Bibliotheken braucht vielleicht weniger.

5. 05

   Buchen Sie früh

   Gute Prüfer sind Wochen im Voraus ausgebucht. Planen Sie das Audit, wenn Sie mit dem Bau beginnen, nicht wenn Sie fertig sind.

Wir bauen und testen Contracts, prüfen sie intern, helfen Ihnen, einen Prüfer zu wählen und zu briefen, und beheben die Befunde. Wir auditieren nicht unsere eigene Arbeit und nennen das unabhängig.