Samoauditující se chytré smlouvy s ChatGPT

Při auditu chytrých smluv je třeba pokrýt celou řadu otázek, aby bylo zajištěno, že kód je bezpečný. Tyto otázky zahrnují různé aspekty včetně řízení přístupu, správy aktiv, správy dat, předpokladů, závislostí a kontrolních seznamů zabezpečení. Níže uvádíme podrobný kontrolní seznam a pokyny pro dotazy ChatGPT, které vás provedou procesem auditu chytrých smluv.

Pokud chcete sami prozkoumat chytrou smlouvu z hlediska zranitelností a skrytých podvodných technik, prvním krokem je správně vytvořený dotaz ChatGPT.

Užitečný dotaz pro ChatGPT by byl následující příkaz:

Poskytněte komplexní seznam všech problémů a zranitelností v následující chytré smlouvě. Podrobně popište problémy a možné zranitelnosti. Uveďte pro každou zranitelnost jeden scénář zneužití. Výstup jako platná tabulka ve formátu markdown se seznamem objektů, každý se sloupci 'popis', 'akce', 'závažnost', 'aktéři', 'scénář', 'typ' a 'řádek'. 'type', kde může být 'usability', 'vulnerability', 'optimization' nebo 'suggestion'. "actors" je seznam zúčastněných subjektů. "závažnost" může být "nízká", "střední" nebo "vysoká". "row" je číslo řádku problému. Ujistěte se, že jsou vyplněna všechna pole v tabulce.

Poté použijte následující otázky k hlubšímu prozkoumání inteligentní smlouvy.

Scénáře využití:

1. Kdo jsou aktéři v systému?


2. Jaké akce má systém?


3. Jaká jsou omezení systému?


4. Jaké jsou potenciální způsoby prolomení systému?


5. Jaká obrana se používá proti útokům?


6. Popište na základě omezení změny stavu jednotlivých funkcí.


7. Uveďte informace o použitých šablonách Solidity a DeFi.


8. Napište pozitivní a negativní axiomy na základě informací o systému.


9. Uveďte způsoby optimalizace a úpravy kódu, aby byl spolehlivější (s ukázkami kódu).


10. Vyjmenujte skryté podvodné metody použité v kódu (pomocí úryvků kódu).

Tip: Vizuální znázornění dat často umožňuje jasnější pochopení fungování systému. Při práci s ChatGPT doporučujeme vyžádat si vizualizaci výstupních dat, například modifikace stavu ve formě diagramů znaků ASCII. I když ne všechny vizualizace mohou dávat smysl, některé mohou poskytnout velmi cenný vhled do fungování chytrého kontraktu.

Ve skutečnosti ChatGPT sice nemůže nahradit lidského auditora, ale významně doplňuje proces auditu tím, že poskytuje jasnější pochopení přechodů stavů protokolu, omezení, invariantů a kompatibility. Tento nástroj je obzvláště efektivní pro pochopení stavových přechodů protokolu a omezení.

Tip: Před zahájením auditu může poskytnutí dokumentace k auditovanému protokolu chatbotu výrazně zlepšit přesnost a relevanci odpovědí. Stačí zmínit: "Toto je dokumentace, která poskytuje nejlepší kontext pro 'název_protokolu', který audituju," a vložit dokument.

Dá se říci, že ChatGPT je výkonný pomocník pro auditory, který poskytuje strukturovaný a hloubkový přístup k auditu chytrých kontraktů. Je však třeba mít na paměti, že ChatGTP (a podobné služby) jsou pouze komplexní interpretací strojové analýzy pracující s pravděpodobnostmi, takže často produkuje chyby a nepřesnosti. Na výsledek ChatGPT se proto nelze plně spoléhat - je to pouze dobrý nástroj ve správných rukou a "výchozí bod" při výzkumu chytrých smluv.

Pro ochranu před možnými riziky je proto třeba chytré kontrakty pečlivěji prozkoumat z hlediska možných zranitelností a podvodných schémat.

Jak provést hloubkový audit chytrých kontraktů? 100 nejčastějších dotazů na ChatGPT

Výše jsme zvážili obecný dotaz (výzvu) na ChatGPT, od kterého můžete začít analyzovat inteligentní kontrakt. Podrobná analýza se však samozřejmě neomezuje pouze na úvodní výzvu.

Podvodníci neustále zdokonalují své taktiky, takže je třeba být informovaný a obezřetný v mnoha ohledech - jedná se o základní strategie, jak ochránit své investice do tokenů.

Podívejme se na seznam 100 nejčastějších dotazů, které vám umožní profesionální přístup k auditu chytrých smluv:

1. Uspěšně se kód zkompiloval?
2. Jaká verze Solidity je v kódu použita? Je to aktuální stabilní verze?"
3. Jsou přítomny jasné komentáře vysvětlující účel funkcí a proměnných?"
4. Používá kontrakt schéma "Ownable"? Pokud ano, pro které funkce?
5. Jsou stavové proměnné správně alokovány pomocí modifikátorů viditelnosti?
6. Jsou použity události pro správné logování?
7. Jsou k dispozici uživatelsky přívětivá chybová hlášení?
8. Je kontrolována návratová hodnota nízkoúrovňových volání?
9. Existují scénáře, kdy se vlastník může autorizovat, což by mohlo vést k tahání za koberec?
10. Kdo má kontrolu nad privilegovanými účty a jaké jsou kontrolní mechanismy?
11. Jaké mechanismy správy existují ve smlouvě a je správa plně otevřená nebo omezená?
12. Jsou v systému používány další smlouvy a jaké role plní (např. smlouva o zastupování)?
13. Je k dispozici mechanismus časového uzamčení a lze jej obejít?
14. Je k dispozici dostatečná dokumentace?
15. Jsou v kódu potenciální zranitelnosti vůči útokům typu DoS nebo reentrancy?
16. Jsou všechny funkce interní kromě těch, které mají být explicitně veřejné/externí?
17. Není v matematických operacích aritmetické přetečení/podtečení?
18. Je použita bezpečná knihovna OpenZeppelin?
19. Nemůže dojít k náhodnému odeslání etheru nebo tokenů na nulovou adresu (0x0)?
20. Před operacemi a změnami stavu se kontrolují podmínky pomocí require?
21. Je stav nastaven před a během provádění akcí?
22. Je použita ochrana proti útokům typu reentry (opětovný vstup) (A volá B volá A)?
23. Je správně implementováno rozhraní ERC20?
24. Používá se modifikátor na více místech, jen pokud je to opravdu nutné?
25. Jsou všechny typy nastaveny explicitně (např. místo uint se používá uint256)?
26. Jsou všechny metody a cykly v rámci maximálního povoleného limitu plynu?
27. Žádné zbytečné inicializace v konstruktoru (nezapomeňte, že jsou nastaveny výchozí hodnoty)?
28. Je zajištěno kompletní pokrytí testů: jsou otestovány všechny metody inteligentního kontraktu a všechny možné typy vstupních dat?
29. Bylo provedeno fuzz testování pomocí náhodných vstupů?
30. Jsou otestovány všechny možné stavy, ve kterých se kontrakt může nacházet?
31. Jsou výchozí množství etherů a tokenů specifikována v jednotkách wei?
32. Přichází blok/čas ukončení crowdsale po bloku/času zahájení (zahájení/povolení obchodování)?
33. Je správně nastaven směnný/konverzní kurz tokenů crowdsale?
34. Je nastaven měkký/tvrdý limit crowdsale?
35. Je nastaven a otestován minimální/maximální povolený příspěvek do crowdsale?
36. Je otestována funkce whitelistingu crowdsale?
37. Je ověřena logika vrácení příspěvku do crowdsale?
38. Obdrží účastníci crowdsale poměrný počet tokenů, nebo si mohou svůj příspěvek nárokovat?
39. Je doba trvání jednotlivých fází crowdsale (např, předprodej, veřejný prodej) správně nakonfigurováno?
40. Je uvedeno, které funkce má ovládat pouze vlastník (např, pozastavení crowdsale, přechod na jinou fázi crowdsale, povolení distribuce tokenů atd...)?
41. Je logika crowdsale vesting (vestování) zkontrolována?
42. Má crowdsale režim fail-safe, který po povolení vlastníkem omezuje volání funkcí a obsahuje funkci vrácení peněz?
43. Má crowdsale funkci nouzového přístupu, pokud to dává rozumný smysl.
44. Byly importované knihovny předem zkontrolovány a neobsahují nežádoucí části, které mohou být v budoucích verzích nahrazeny a mohly by být použity ke škodlivým účelům?
45. Metody přenosu tokenů (transfer) zabalené do require?
46. Jsou require a assert použity správně? Metoda assert se používá pouze pro věci, které by se nikdy neměly stát, obvykle se používá pro kontrolu stavu po provedených změnách.
47. Existuje obrana proti útokům rekurzivním voláním?
48. Jsou omezeny délky libovolných řetězců na vstupu?
49. Pokud je to možné, vyhněte se používání polí a použijte místo nich mapování?
50. Nepoužívají se blokové hashe pro zpracování náhodných hodnot (těžaři to mohou ovlivnit)?
51. Nikde se nepoužívá tx.origin?
52. Prvky pole se při mazání prvku posouvají dolů, aby nezůstávaly mezery?
53. Používá se revert místo throw?
54. Funkce se ukončí okamžitě, pokud nejsou splněny podmínky?
55. Jsou vyřešena varování kompilátoru?
56. Používá se při výpočtech knihovna SafeMath?
57. Jsou některé paměťové sloty (storage sloty) čteny více než jednou?
58. Používají se neohraničené smyčky/ pole, které by mohly způsobit DoS?
59. Používá se block.timestamp pouze pro dlouhé intervaly?
60. Nepoužívá se block. number pro výpočet uplynulého času?
61. Vyhýbá se volání delegatecall, zejména u externích (i když důvěryhodných) kontraktů?
62. Neaktualizuje se délka pole při iteraci nad ním?
63. Jsou podpisy chráněny před přehráním pomocí nonce a block.chainid?
64. Ujistěte se, že všechny podpisy používají EIP-712?
65. Výstup abi.encodePacked() by neměl být hashován, pokud jsou použity více než 2 dynamické typy. Obecně je vhodnější použít abi.encode().
66. Důkladně zkontrolujte vkládání kódu assembleru.
67. Vyhněte se nedostatečné spotřebě plynu (gas griefing).
68. Jsou všechna soukromá data skutečně soukromá?
69. Aktualizace struktury/ pole v paměti (memory) ji nezmění v úložišti (stage)?
70. Jsou proměnné stage zastíněné?
71. Je výpočet hodnoty proměnné za běhu levnější než její uložení?
72. Jsou všechny stavové proměnné načítány ze správného kontraktu (master vs. clone)?
73. Jsou správně používány operátory porovnávání (>, <, >=, <=), zejména aby se zabránilo chybám off-by-one?
74. Jsou logické operátory (==, ! =, &&, ||, !) používány správně, zejména aby se zabránilo chybám mimo jednotku?
75. Provádí se násobení vždy před dělením (pokud násobení nemůže přetéct)?
76. Jsou magická čísla nahrazena konstantou s intuitivním názvem?
77. Pokud má příjemce ETH zpětnou (fallback ) funkci, kterou lze vrátit, může to vést k DoS?
78. Používá se standard SafeERC20 a kontrolují se návratové hodnoty bezpečným způsobem?
79. Předpokládá se, že msg. odesílatelem je vždy relevantní uživatel?
80. Nepoužívá se pro autorizaci funkce .origin?
81. Nepoužívá se místo funkce .call.value() funkce address.transfer() nebo address.send()?
82. Při použití nízkoúrovňových volání se ujistěte, že před voláním existuje smlouva.
83. Používá se kód assembleru pro přístup k chainid nebo kód/velikost/hash kontraktu místo syntaxe Solidity?
84. Používá se klíčové slovo delete při nastavování proměnné na nulovou hodnotu (0, false, "" atd..)?
85. Výrazy předávané logickým operátorům/porovnáním (&&/|||/>=/==/atd..) nesmí mít vedlejší účinky.
86. Při práci s více adresami si položte otázku, co se stane, pokud jsou stejné?
87. Jak dobře je kód zdokumentován? Jsou uvedeny komentáře a příklady všude tam, kde je použit nestandardní kód?
88. Pokud je použito externí volání, ujistěte se, že je volání externí smlouvy opravdu nutné?
89. Je výsledek externího volání kontrolován a jsou ošetřeny chyby?
90. Co se stane, pokud externí volání použije všechny poskytnuté plyny?
91. Pokud externí volání volá konkrétní funkci, ujistěte se, že tato funkce skutečně existuje (fantomové funkce).
92. Ujistěte se, že v modifikátorech nejsou použita žádná externí volání (modifikátory)
93. Jsou pro každou funkci, která modifikuje úložiště, vydávány události?
94. Zkontrolujte své předpoklady o tom, co dělají a vracejí externí smlouvy použité v mainu.
95. Dejte si pozor na tokeny, které používají příliš mnoho nebo příliš málo desetinných míst. Ujistěte se, že jsou zdokumentovány maximální a minimální podporované hodnoty.
96. Jsou zdokumentovány pravomoci spojené s rolemi?
97. Jaká jsou rizika při porušení přístupových práv a jak to může ovlivnit různé součásti systému?
98. Může vlastník manipulovat s tokeny a ETH v rámci kontraktu?
99. Jak je nastavena adresa oracle (Oracle) a jaký proces za tím stojí? Existují náhradní oracly pro zálohování?
100. Jak jsou podobné funkce implementovány v jiných projektech, byly zohledněny osvědčené postupy?

Tento kontrolní seznam vám pomůže zajistit provedení důkladného bezpečnostního auditu chytrých kontraktů Solidity. Zahrnuje širokou škálu kritických aspektů pro identifikaci a zmírnění potenciálních zranitelností a rizik v kódu a souvisejících systémech.

 

Doufáme, že vám tyto příklady pomohly lépe pochopit metodiku auditu chytrých smluv.

 

Jelikož jsou všechny informace v blockchainu otevřené (samozřejmě za předpokladu, že je ověřen zdrojový kód smlouvy), můžete vyzbrojeni těmito znalostmi nezávisle studovat chytré smlouvy a identifikovat různá podvodná schémata.

Však už jsme to všechno udělali za vás! Přihlaste se k prémiovému předplatnému a získejte přístup k exkluzivním filtrům funkcí chytrých kontraktů a čerstvým analýzám. Zvyšte své šance na úspěšné investování do výnosných tokenů.

S pozdravem, tým Lotus Market.

All posts