Selbst-Auditierung von Smart Contracts mit ChatGPT

Bei der Prüfung von intelligenten Verträgen muss ein breites Spektrum an Fragen abgedeckt werden, um sicherzustellen, dass der Code sicher ist. Diese Fragen decken verschiedene Aspekte ab, darunter Zugriffskontrolle, Asset-Management, Datenmanagement, Annahmen, Abhängigkeiten und Sicherheitschecklisten. Nachfolgend finden Sie eine detaillierte Checkliste und Anweisungen für ChatGPT-Abfragen, die Sie durch den Prozess der Smart-Contract-Prüfung führen.

Wenn Sie einen Smart Contract selbst auf Schwachstellen und versteckte Betrugstechniken untersuchen wollen, ist der erste Schritt eine korrekt gestaltete ChatGPT-Eingabeaufforderung.

Eine nützliche Abfrage für ChatGPT wäre der folgende Befehl:

Erstellen Sie eine umfassende Liste aller Probleme und Schwachstellen in dem folgenden Smart Contract. Beschreiben Sie die Probleme und möglichen Schwachstellen im Detail. Geben Sie für jede Schwachstelle ein Ausnutzungsszenario an. Ausgabe als gültige Tabelle im Markdown-Format mit einer Liste von Objekten, jeweils mit den Spalten 'Beschreibung', 'Aktion', 'Schweregrad', 'Akteure', 'Szenario', 'Typ' und 'Zeile'. Typ" kann "Benutzerfreundlichkeit", "Schwachstelle", "Optimierung" oder "Vorschlag" sein. Akteure" ist eine Liste der beteiligten Akteure. Schweregrad" kann "niedrig", "mittel" oder "hoch" sein. Zeile" ist die Zeilennummer des Problems. Stellen Sie sicher, dass alle Felder in der Tabelle ausgefüllt sind.

Verwenden Sie dann die folgenden Fragen, um den intelligenten Vertrag näher zu untersuchen.

Verwendungsszenarien:

1. Wer sind die Akteure in diesem System?


2. Welche Aktionen hat das System?


3. Was sind die Grenzen des Systems?


4. Welche Möglichkeiten gibt es, das System zu durchbrechen?


5. Welche Abwehrmaßnahmen werden gegen die Angriffe eingesetzt?


6. Beschreiben Sie die Zustandsänderungen der einzelnen Funktionen auf der Grundlage der Nebenbedingungen.


7. Geben Sie Informationen über die verwendeten Solidity- und DeFi-Vorlagen an.


8. Schreiben Sie positive und negative Axiome auf der Grundlage von Informationen über das System.


9. Auflisten von Möglichkeiten zur Optimierung und Änderung des Codes, um ihn zuverlässiger zu machen (mit Codeschnipseln).


10. Nennen Sie die im Code verwendeten versteckten Betrugsmethoden (mit Codeschnipseln).

Tipp: Die visuelle Darstellung von Daten führt oft zu einem besseren Verständnis des Systembetriebs. Bei der Arbeit mit ChatGPT empfiehlt es sich, Visualisierungen von Ausgabedaten, wie z. B. Zustandsänderungen, in Form von ASCII-Zeichendiagrammen anzufordern. Auch wenn nicht alle Visualisierungen sinnvoll sind, können einige sehr wertvolle Einblicke in die Funktionsweise eines Smart Contracts geben.

Auch wenn ChatGPT einen menschlichen Prüfer nicht ersetzen kann, so ergänzt es doch den Prüfungsprozess erheblich, indem es ein klareres Verständnis von Protokollzustandsübergängen, Einschränkungen, Invarianten und Kompatibilität vermittelt. Dieses Tool ist besonders effektiv für das Verständnis von Protokollzustandsübergängen und -einschränkungen.

Tipp: Wenn Sie dem Chatbot vor Beginn eines Audits die Dokumentation zu dem zu prüfenden Protokoll zur Verfügung stellen, können Sie die Genauigkeit und Relevanz der Antworten erheblich verbessern. Erwähnen Sie einfach: "Dies ist die Dokumentation, die den besten Kontext für das 'protocol_name' liefert, das ich überprüfe", und fügen Sie das Dokument ein.

Man kann sagen, dass ChatGPT ein leistungsstarker Assistent für Prüfer ist, der einen strukturierten und detaillierten Ansatz für die Prüfung von Smart Contracts bietet. Es sollte jedoch bedacht werden, dass ChatGPT (und ähnliche Dienste) lediglich komplexe Interpretationen maschineller Analysen sind, die mit Wahrscheinlichkeiten arbeiten, so dass sie oft Fehler und Ungenauigkeiten produzieren. Dementsprechend kann man sich auf das Ergebnis von ChatGPT nicht vollständig verlassen - es ist nur ein gutes Werkzeug in den richtigen Händen und ein "Ausgangspunkt" für die Erforschung von Smart Contracts.

Um sich vor möglichen Risiken zu schützen, sollten intelligente Verträge daher genauer auf mögliche Schwachstellen und betrügerische Machenschaften untersucht werden.

Wie führt man eine eingehende Prüfung von Smart Contracts durch? Top 100 Anfragen an ChatGPT

Oben haben wir eine allgemeine Anfrage (Prompt) an ChatGPT betrachtet, mit der Sie die Analyse eines Smart Contracts beginnen können. Aber natürlich ist die detaillierte Analyse nicht auf die einleitende Aufforderung beschränkt.

Da Betrüger ihre Taktiken ständig verbessern, müssen Sie in vielerlei Hinsicht informiert und vorsichtig sein - dies sind die wichtigsten Strategien zum Schutz Ihrer Token-Investition.

Werfen wir einen Blick auf eine Liste der 100 wichtigsten Abfragen, die Ihnen einen professionellen Ansatz für ein Smart Contract Audit bieten:

1. Ist der Code erfolgreich kompiliert?
2. Welche Version von Solidity wird im Code verwendet? Ist es die aktuelle stabile Version?
3. Gibt es klare Kommentare, die den Zweck von Funktionen und Variablen erklären?
4. Verwendet der Vertrag ein "Ownable"-Schema? Wenn ja, für welche Funktionen?
5. Sind die Zustandsvariablen mit Hilfe von Sichtbarkeitsmodifikatoren korrekt zugeordnet?
6. Werden Ereignisse für eine ordnungsgemäße Protokollierung verwendet?
7. Gibt es benutzerfreundliche Fehlermeldungen?
8. Wird der Rückgabewert von Low-Level-Aufrufen überprüft?
9. Gibt es Szenarien, in denen der Eigentümer sich selbst ermächtigen kann, die zu einem Rugpulling führen könnten?
10. Wer hat die Kontrolle über privilegierte Konten und wie sehen die Kontrollmechanismen aus?
11. Welche Governance-Mechanismen sind in dem Vertrag vorgesehen, und ist die Governance völlig offen oder begrenzt?
12. Werden andere Verträge im System verwendet und welche Aufgaben erfüllen sie (z. B. Proxy-Vertrag)?
13. Gibt es einen Zeitsperrmechanismus und kann dieser umgangen werden?
14. Ist eine angemessene Dokumentation vorhanden?
15. Gibt es im Code potenzielle Schwachstellen für DoS- oder Reentrancy-Angriffe?
16. Sind alle Funktionen intern, außer denen, die ausdrücklich öffentlich/extern sein sollen?
17. Keine arithmetischen Überläufe/Unterläufe bei mathematischen Operationen?
18. Wird die sichere OpenZeppelin-Bibliothek verwendet?
19. Ether oder Token können nicht versehentlich an eine Null-Adresse (0x0) gesendet werden?
20. Bedingungen werden mit require vor Operationen und Zustandsänderungen geprüft?
21. Ist der Zustand vor und während der Ausführung von Aktionen festgelegt?
22. Wird ein Schutz gegen Wiedereinreise-Angriffe (A ruft B ruft A) verwendet?
23. Ist die ERC20-Schnittstelle ordnungsgemäß implementiert?
24. Wird der Modifikator nur dann an mehreren Stellen verwendet, wenn er wirklich notwendig ist?
25. Sind alle Typen explizit festgelegt (z. B. wird uint256 anstelle von uint verwendet)?
26. Liegen alle Methoden und Zyklen innerhalb der maximal zulässigen Gasgrenze?
27. Keine unnötigen Initialisierungen im Konstruktor (denken Sie daran, dass Standardwerte gesetzt sind)?
28. Es gibt eine vollständige Testabdeckung: jede Smart-Contract-Methode und alle möglichen Eingabedatentypen werden getestet?
29. Wurden Fuzz-Tests mit zufälligen Eingaben durchgeführt?
30. Werden alle möglichen Zustände, die ein Vertrag haben kann, getestet?
31. Die Standardmengen an Äther und Token werden in Einheiten von wei?
32. Kommt das Ende des Crowdsale-Blocks/der Endzeit nach dem Startblock/der Startzeit (Start/Aktivierung des Handels)?
33. Ist der Umtausch- bzw. Umrechnungskurs von Crowdsale-Tokens korrekt eingestellt?
34. Gibt es ein weiches/hartes Crowdsale-Limit?
35. Ist der zulässige Mindest-/Höchstbeitrag für Crowdsale festgelegt und getestet?
36. Wurde die Whitelisting-Funktion von Crowdsales getestet?
37. Wurde die Rückerstattungslogik der Crowdsale-Aktion überprüft?
38. Erhalten Crowdsale-Teilnehmer eine anteilige Anzahl von Token oder können sie ihren Beitrag einfordern?
39. Ist die Dauer der einzelnen Phasen des Crowdsale (z. B. Vorverkauf, öffentlicher Verkauf) richtig konfiguriert?
40. Ist festgelegt, welche Funktionen nur vom Eigentümer kontrolliert werden dürfen (z. B. das Anhalten des Crowdsale, der Übergang zu einer anderen Phase des Crowdsale, die Aktivierung der Token-Verteilung usw.)?
41. Wurde die Crowdsale-Vesting-Logik (Unverfallbarkeit) überprüft?
42. Crowdsale verfügt über einen ausfallsicheren Modus, der, wenn er vom Eigentümer aktiviert wird, die Aufrufe von Funktionen begrenzt und eine Rückerstattungsfunktion enthält?
43. Crowdsale hat eine Ausweichfunktion, wenn dies sinnvoll ist.
44. Wurden die importierten Bibliotheken vorab geprüft und enthalten sie keine unerwünschten Teile, die in zukünftigen Versionen ersetzt werden und für bösartige Zwecke verwendet werden könnten?
45. Token-Transfer-Methoden (Transfer) verpackt in require?
46. Werden require und assert richtig verwendet? Die assert-Methode wird nur für Dinge verwendet, die nie passieren sollten. Normalerweise wird sie verwendet, um den Zustand zu überprüfen, nachdem Änderungen vorgenommen wurden.
47. Gibt es einen Schutz vor rekursiven Angriffen?
48. Sind die Längen beliebiger Zeichenketten in der Eingabe begrenzt?
49. Wenn möglich, vermeiden Sie die Verwendung von Arrays und verwenden Sie stattdessen Mappings?
50. Werden Blockhashes nicht zur Verarbeitung von Zufallswerten verwendet (Miner können dies beeinflussen)?
51. Wird tx.origin nirgends verwendet?
52. Array-Elemente werden nach unten verschoben, wenn ein Element gelöscht wird, um keine Lücken zu hinterlassen?
53. Wird revert anstelle von throw verwendet?
54. Werden die Funktionen sofort beendet, wenn die Bedingungen nicht erfüllt sind?
55. Wurden die Compilerwarnungen behoben?
56. Wird die SafeMath-Bibliothek für Berechnungen verwendet?
57. Wird ein Speicherplatz mehr als einmal gelesen?
58. Werden unbeschränkte Schleifen/Arrays verwendet, die DoS verursachen könnten?
59. Wird block.timestamp nur für lange Intervalle verwendet?
60. Verwenden Sie block.number nicht zur Berechnung der verstrichenen Zeit?
61. Wird der Delegatecall-Aufruf vermieden, insbesondere bei externen (wenn auch vertrauenswürdigen) Verträgen?
62. Wird die Länge des Arrays nicht aktualisiert, wenn darüber iteriert wird?
63. Sind Signaturen mit nonce und block.chainid vor Wiederholung geschützt?
64. Stellen Sie sicher, dass alle Unterschriften mit dem EIP-712?
65. Die Ausgabe von abi.encodePacked() sollte nicht gehasht werden, wenn mehr als 2 dynamische Typen verwendet werden. Im Allgemeinen ist es vorzuziehen, abi.encode() zu verwenden.
66. Prüfen Sie sorgfältig die Einfügung von Assembly-Code.
67. Vermeiden Sie unzureichenden Gasverbrauch (Gas Griefing).
68. Sind alle privaten Daten wirklich privat?
69. Die Aktualisierung einer Struktur/eines Arrays im Speicher (Memory) führt nicht zu einer Änderung im Storage (Stage)?
70. Werden die Bühnenvariablen überlagert?
71. Ist es billiger, den Wert einer Variablen im laufenden Betrieb zu berechnen als ihn zu speichern?
72. Werden alle Zustandsvariablen aus dem richtigen Vertrag (Master vs. Klon) gelesen?
73. Werden die Vergleichsoperatoren (>, <, >=, <=) korrekt verwendet, vor allem um Fehler zu vermeiden, die nicht auf einer Linie liegen?
74. Werden die logischen Operatoren (==, !=, &&, ||, !) korrekt verwendet, insbesondere zur Vermeidung von Off-by-One-Fehlern?
75. Wird die Multiplikation immer vor der Division durchgeführt (es sei denn, die Multiplikation kann überlaufen)?
76. Werden magische Zahlen durch eine Konstante mit einem intuitiven Namen ersetzt?
77. Wenn ein ETH-Empfänger eine Fallback-Funktion (Rückfallfunktion) hat, die rückgängig gemacht werden kann, könnte dies zu einem DoS führen?
78. Wird der SafeERC20-Standard verwendet und werden die Rückgabewerte auf sichere Weise geprüft?
79. Wird davon ausgegangen, dass der msg.sender immer ein relevanter Benutzer ist?
80. Wird tx.origin nicht für die Autorisierung verwendet?
81. Wird nicht address.transfer() oder address.send() anstelle von .call.value() verwendet?
82. Wenn Sie Low-Level-Aufrufe verwenden, stellen Sie sicher, dass vor dem Aufruf ein Vertrag besteht.
83. Wird Assemblercode für den Zugriff auf chainid oder Vertragscode/Größe/Hash anstelle der Solidity-Syntax verwendet?
84. Wird das Schlüsselwort delete verwendet, wenn eine Variable auf einen Nullwert (0, false, "", usw..) gesetzt wird?
85. Ausdrücke, die an logische Operatoren/Vergleiche (&&/||/>=/==/usw.) übergeben werden, dürfen keine Nebeneffekte haben.
86. Wenn Sie mit mehreren Adressen zu tun haben, fragen Sie sich, was passiert, wenn die Adressen identisch sind?
87. Wie gut ist der Code dokumentiert? Gibt es Kommentare und Beispiele, wenn nicht standardisierter Code verwendet wird?
88. Wenn ein externer Anruf verwendet wird, stellen Sie sicher, dass ein externer Vertragsanruf wirklich notwendig ist.
89. Wird das Ergebnis des externen Aufrufs überprüft und werden Fehler behandelt?
90. Was passiert, wenn der Externe Anruf das gesamte bereitgestellte Gas verbraucht?
91. Wenn Externer Aufruf eine bestimmte Funktion aufruft, stellen Sie sicher, dass die Funktion tatsächlich existiert (Phantomfunktionen).
92. Achten Sie darauf, dass in den Modifikatoren keine externen Aufrufe verwendet werden (Modifikatoren)
93. Werden für jede Funktion, die den Speicher verändert, Ereignisse ausgegeben?
94. Überprüfen Sie Ihre Annahmen darüber, was die im Wesentlichen verwendeten externen Verträge leisten und was sie einbringen.
95. Achten Sie auf Token, die zu viele oder zu wenige Dezimalstellen verwenden. Stellen Sie sicher, dass die maximal und minimal unterstützten Werte dokumentiert sind.
96. Ist die mit den Rollen verbundene Autorität dokumentiert?
97. Welche Risiken bestehen, wenn die Zugriffsrechte verletzt werden, und wie kann sich dies auf die verschiedenen Komponenten des Systems auswirken?
98. Kann der Besitzer Token und ETH innerhalb des Vertrags manipulieren?
99. Wie wird die Adresse des Orakels (Oracle) festgelegt und welches Verfahren steht dahinter? Gibt es Ersatzorakel für die Datensicherung?
100. Wie werden ähnliche Funktionen in anderen Projekten umgesetzt, wurden bewährte Verfahren berücksichtigt?

Diese Checkliste hilft Ihnen, eine gründliche Sicherheitsprüfung von Solidity-Smart Contracts durchzuführen. Sie deckt ein breites Spektrum an kritischen Aspekten ab, um potenzielle Schwachstellen und Risiken im Code und den zugehörigen Systemen zu identifizieren und zu mindern.

 

Wir hoffen, dass diese Beispiele Ihnen geholfen haben, die Methodik der Prüfung von Smart Contracts besser zu verstehen.

 

Da alle Informationen in der Blockchain offen liegen (vorausgesetzt natürlich, dass der Quellcode des Vertrags verifiziert ist), können Sie mit diesem Wissen intelligente Verträge unabhängig untersuchen und verschiedene Betrugsversuche erkennen.

Aber wir haben schon alles für Sie getan! Melden Sie sich für ein Premium-Abonnement an und erhalten Sie Zugang zu exklusiven Filtern für Smart Contracts-Funktionen und neuen Analysen. Erhöhen Sie Ihre Chancen, erfolgreich in profitable Token zu investieren.

Mit freundlichen Grüßen, Lotus Market Team.

All posts