Önellenőrző intelligens szerződések a ChatGPT-vel

Az intelligens szerződések ellenőrzése során számos kérdésre kell figyelni ahhoz, hogy a kód biztonságos legyen. Ezek a kérdések különböző szempontokat érintenek, beleértve a hozzáférés-szabályozást, az eszközkezelést, az adatkezelést, a feltételezéseket, a függőségeket és a biztonsági ellenőrző listákat. Az alábbiakban részletes ellenőrző listát és utasításokat adunk a ChatGPT lekérdezésekhez, hogy végigvezessük az okosszerződések auditálási folyamatán.

Ha saját maga szeretne megvizsgálni egy okosszerződést sebezhetőségek és rejtett csalási technikák szempontjából, az első lépés egy helyesen elkészített ChatGPT lekérdezés.

A ChatGPT számára hasznos lekérdezés a következő parancs lenne:

Adjon egy átfogó listát a következő okosszerződés összes problémájáról és sebezhetőségéről. Írja le részletesen a problémákat és a lehetséges sebezhetőségeket. Adjon meg egy kihasználási forgatókönyvet minden egyes sebezhetőséghez. Kimenete egy érvényes táblázat formájában, markdown formátumban, objektumok listájával, mindegyik oszlopban a 'description', 'action', 'severity', 'actors', 'scenario', 'type' és 'line' oszlopokkal. A "típus" lehet "használhatóság", "sebezhetőség", "optimalizálás" vagy "javaslat". 'actors' az érintett szereplők listája. a "súlyosság" lehet "alacsony", "közepes" vagy "magas". 'row' a probléma sorszáma. Győződjön meg róla, hogy a táblázat minden mezője ki van töltve.

Az alábbi kérdések segítségével aztán mélyebben megvizsgálhatja az okos szerződést.

Használati forgatókönyvek:

1. Kik a rendszer szereplői?


2. Milyen műveletekkel rendelkezik a rendszer?


3. Melyek a rendszer korlátai?


4. Melyek a rendszer feltörésének lehetséges módjai?


5. Milyen védekezéseket alkalmaznak a támadások elhárítására?


6. Írd le a korlátozások alapján az egyes funkciók állapotváltozásait.


7. Adjon információt a használt Solidity és DeFi sablonokról.


8. Írjon pozitív és negatív axiómákat a rendszerre vonatkozó információk alapján.


9. Sorolja fel a kód optimalizálásának és módosításának módjait, hogy megbízhatóbbá tegye azt (kódrészletekkel).


10. Listázza a kódban használt rejtett átverési módszereket (kódrészletekkel).

Tipp: Az adatok vizuális megjelenítése gyakran világosabb képet ad a rendszer működéséről. A ChatGPT-vel való munka során ajánlott a kimeneti adatok, például az állapotváltozások vizuális megjelenítését ASCII karakterdiagramok formájában kérni. Bár nem minden vizualizációnak lehet értelme, néhány nagyon értékes betekintést nyújthat egy okos szerződés működésébe.

Tény, hogy bár a ChatGPT nem helyettesítheti az emberi auditorokat, jelentősen kiegészíti az auditálási folyamatot, mivel világosabb képet ad a protokoll állapotátmenetekről, a korlátozásokról, az invarianciákról és a kompatibilitásról. Ez az eszköz különösen hatékony a protokollállapot-átmenetek és a korlátozások megértésében.

Tipp: Az auditálás megkezdése előtt, ha a chatbotot ellátjuk az auditálandó protokoll dokumentációjával, jelentősen javíthatjuk a válaszok pontosságát és relevanciáját. Csak említse meg: "Ez az a dokumentáció, amely a legjobb kontextust biztosítja az általam auditált 'protokoll_név' számára", és illessze be a dokumentumot."

Mondhatjuk, hogy a ChatGPT egy hatékony asszisztens az auditorok számára, amely strukturált és mélyreható megközelítést biztosít az okos szerződések auditálásához. Ugyanakkor szem előtt kell tartani, hogy a ChatGTP (és a hasonló szolgáltatások) csupán a valószínűségekkel dolgozó gépi elemzés összetett értelmezései, így gyakran produkál hibákat és pontatlanságokat. Ennek megfelelően a ChatGPT eredményére nem lehet teljes mértékben támaszkodni - ez csak egy jó eszköz a megfelelő kezekben, és egy "kiindulópont" az okosszerződések kutatásában.

Ezért a lehetséges kockázatokkal szembeni védelem érdekében az okosszerződéseket alaposabban meg kell vizsgálni a lehetséges sebezhetőségek és csalárd rendszerek szempontjából.

Hogyan végezzen alapos okosszerződés-ellenőrzést? Top 100 kérés a ChatGPT-hez

Fentebb egy általános lekérdezést (prompt) tekintettünk át a ChatGPT-hez, amelyből kiindulva elkezdhetjük egy okosszerződés elemzését. De természetesen a részletes elemzés nem korlátozódik a bevezető promptra.

A csalók folyamatosan fejlesztik a taktikájukat, ezért sok szempontból tájékozottnak és óvatosnak kell lenned - ezek alapvető stratégiák a tokenbefektetésed védelméhez.

Nézzük meg a top 100 lekérdezés listáját, amelyek segítségével professzionális megközelítéssel végezhetsz okosszerződés-ellenőrzést:

1. A kód sikeresen fordítható?
2. Milyen Solidity-verziót használ a kód? Az aktuális stabil verzió?
3. Megvannak-e a függvények és változók célját magyarázó egyértelmű megjegyzések?
4. A szerződés "Ownable" sémát használ? Ha igen, mely függvények esetében?
5. Az állapotváltozókat helyesen osztják ki a láthatóságmódosítók használatával?
6. A megfelelő naplózáshoz eseményeket használnak?
7. Bizonyos felhasználóbarát hibaüzeneteket adnak?
8. Az alacsony szintű hívások visszatérési értékét ellenőrzik?
9. Vannak olyan forgatókönyvek, ahol a tulajdonos felhatalmazhatja magát, ami szőnyeghúzáshoz vezethet?
10. Ki rendelkezik a kiváltságos fiókok felett, és milyen ellenőrzési mechanizmusok vannak?
11. Milyen irányítási mechanizmusok vannak a szerződésben, és az irányítás teljesen nyitott vagy korlátozott?
12. A rendszerben más szerződéseket is használnak, és azok milyen szerepet töltenek be (pl. proxy-szerződés)?
13. Létezik-e időzárolási mechanizmus, és megkerülhető-e?
14. Megfelelő dokumentáció áll rendelkezésre?
15. Létezik-e a kódban DoS- vagy reentrancia-támadások potenciális sebezhetősége?
16. Minden függvény belső, kivéve azokat, amelyeknek kifejezetten nyilvánosnak/külsőnek kell lenniük?
17. Nincs aritmetikai túlcsordulás/alulcsordulás a matematikai műveletekben?
18. A biztonságos OpenZeppelin könyvtárat használják?
19. Eter vagy tokenek nem küldhetők véletlenül nullcímre (0x0)?
20. A feltételek ellenőrzése a require segítségével történik a műveletek és állapotváltozások előtt?
21. Az állapotot a műveletek végrehajtása előtt és közben beállítják?
22. Védelmet alkalmaznak a reentry (visszalépés) támadások ellen (A hívja B hívja A-t)?
23. Az ERC20 interfész megfelelően implementálva van?
24. A módosító több helyen csak akkor használatos, ha valóban szükséges?
25. Az összes típus explicit módon van beállítva (pl. uint256 helyett uint-et használnak)?
26. Az összes módszer és ciklus a megengedett maximális gázhatáron belül van?
27. Nincs szükségtelen inicializálás a konstruktorban (ne feledje, hogy az alapértelmezett értékek be vannak állítva)?
28. Teljes a tesztelés lefedettsége: minden intelligens szerződés metódus és minden lehetséges bemeneti adattípus tesztelve van?
29. Végeztek fuzz tesztelést véletlenszerű bemenetekkel?
30. Tesztelték az összes lehetséges állapotot, amelyben egy szerződés lehet?
31. Az ether és a tokenek alapértelmezett mennyiségei wei egységben vannak megadva?
32. A crowdsale végblokk/időpont a start blokk/időpont után következik (kereskedés indítása/engedélyezése)?
33. A crowdsale tokenek csere/átváltási aránya helyesen van beállítva?
34. Kemény/kemény crowdsale limit van beállítva?
35. A crowdsale-hez való minimális/maximális megengedett hozzájárulás be van állítva és tesztelve?
36. Tesztelték a crowdsale fehérlistás funkcióját?
37. A crowdsale visszatérítési logikáját ellenőrizték?
38. A crowdsale résztvevői arányos számú tokent kapnak, vagy igényelhetik a hozzájárulásukat?
39. A crowdsale egyes szakaszainak időtartama (pl., előértékesítés, nyilvános értékesítés) megfelelően konfigurálva?
40. Meg van határozva, hogy mely funkciókat csak a tulajdonos ellenőrizheti (pl, a crowdsale szüneteltetése, a crowdsale egy másik szakaszára való áttérés, a tokenek elosztásának engedélyezése stb.)?
41. A crowdsale megszolgálási (vesting) logikája ki lett ellenőrizve?
42. A crowdsale rendelkezik hibabiztos üzemmóddal, amely, ha a tulajdonos engedélyezi, korlátozza a funkcióhívásokat, és tartalmaz egy visszatérítési funkciót?
43. A Crowdsale rendelkezik visszaesési funkcióval, ha annak ésszerű értelme van.
44. Az importált könyvtárakat előzetesen ellenőrizték, és nem tartalmaznak nemkívánatos részeket, amelyeket a jövőbeli verziókban lecserélhetnek, és rosszindulatú célokra használhatnak?
45. A tokenátviteli módszereket (transfer) require-be csomagolták?
46. A require és assert helyesen használják? Az assert metódust csak olyan dolgokra használjuk, amiknek soha nem szabadna megtörténniük, általában a módosítások utáni állapot ellenőrzésére szolgál.
47. Védekezés a rekurzív hívástámadások ellen?
48. A bemenetben lévő tetszőleges karakterláncok hossza korlátozott?
49. Ahol lehetséges, kerüljük a tömbök használatát, és használjunk helyettük leképezéseket?
50. Nem használnak blokk hash-eket véletlenszerű értékek kezelésére (a bányászok ezt befolyásolhatják)?
51. Nem használnak tx.origin-t sehol?
52. A tömb elemeit lefelé tolják, amikor egy elemet törölnek, hogy ne maradjanak hézagok?
53. A throw helyett a revert-et használják?
54. A funkciók azonnal befejeződnek, ha a feltételek nem teljesülnek?
55. A fordítói figyelmeztetések megoldódtak?
56. A SafeMath könyvtárat használják a számításokban?
57. Minden memóriahelyet (tárolóhelyet) többször is olvasnak?
58. Használnak-e olyan korlátlan ciklusokat/táblázatokat, amelyek DoS-t okozhatnak?
59. A block.timestamp csak hosszú intervallumok esetén használatos?
60. Nem használnak block. number-t az eltelt idő kiszámításához?
61. A delegatecall hívás kerülendő, különösen külső (még ha megbízható) szerződések esetén?
62. Nem frissül a tömb hossza, miközben iteráljuk rajta?
63. Az aláírások a nonce és a block.chainid segítségével védettek a visszajátszástól?
64. Győződjön meg róla, hogy minden aláírás az EIP-712-t használja?
65. Az abi.encodePacked() kimenetét nem szabad hashedelni, ha 2-nél több dinamikus típus van használatban. Általában előnyösebb az abi.encode() használata.
66. Gondosan ellenőrizze az assembly kód beszúrásokat.
67. Kerülje el a nem megfelelő gázfogyasztást (gas griefing).
68. Minden privát adat valóban privát?
69. Egy struktúra/tömb frissítése a memóriában (memória) nem változtatja meg a tárolásban (stage)?
70. A stage változók árnyékolva vannak?
71. Egy változó értékének menet közbeni kiszámítása olcsóbb, mint a tárolása?
72. Az összes állapotváltozót a megfelelő szerződésből olvassák (master vs. klón)?
73. Az összehasonlító operátorokat (>, <, >=, <=) helyesen használják, különösen az egy az egyhez hibák elkerülése érdekében?
74. A logikai operátorok (==, ! =, &&, ||, !) helyesen használatosak, különösen az egy az egyhez hibák elkerülése érdekében?
75. A szorzás mindig az osztás előtt történik (kivéve, ha a szorzás túlcsordulhat)?
76. A bűvös számokat egy intuitív nevű konstanssal helyettesítik?
77. Ha egy ETH címzettnek van egy visszafordítható (fallback ) függvénye, ez DoS-hez vezethet?
78. A SafeERC20 szabványt használják, és a visszatérési értékeket biztonságos módon ellenőrzik?
79. Azt feltételezik, hogy a msg. feladó mindig releváns felhasználó?
80. Nem használjuk az engedélyezéshez a tx.origin-t?
81. Nem használjuk a address.transfer() vagy address.send() helyett a .call.value() funkciót?
82. Az alacsony szintű hívások használatakor győződjünk meg arról, hogy a hívás előtt létezik-e szerződés.
83. Az assembly kódot használják a chainid vagy a szerződés kód/méret/hash eléréséhez a Solidity szintaxis helyett?
84. A delete kulcsszót használják, amikor egy változót null értékre (0, false, "", stb.) állítanak?
85. A logikai operátoroknak/összehasonlításoknak (&&/|||/>=/==/ stb) átadott kifejezéseknek nem lehetnek mellékhatásai.
86. Mikor több címmel dolgozunk, kérdezzük meg, mi történik, ha azok azonosak?
87. Mennyire jól dokumentált a kód? Vannak-e megjegyzések és példák mindenütt, ahol nem szabványos kódot használnak?
88. Ha külső hívást használnak, győződjenek meg arról, hogy a külső szerződés hívására valóban szükség van?
89. A külső hívás eredményét ellenőrzik, és kezelik-e a hibákat?
90. Mi történik, ha a külső hívás az összes megadott gázt felhasználja?
91. Ha a külső hívás egy adott függvényt hív, győződjenek meg arról, hogy a függvény valóban létezik (fantomfüggvények).
92. Győződjön meg róla, hogy a módosítókban nem használnak külső hívásokat (módosítók)
93. Minden olyan függvényhez, amely módosítja a tárolást, eseményeket adnak ki?
94. Ellenőrizze a feltételezéseit arról, hogy a mainban használt külső szerződések mit csinálnak és mit adnak vissza.
95. Vigyázzon a túl sok vagy túl kevés tizedesjegyet használó tokenekre. Győződjön meg róla, hogy a maximális és minimális támogatott értékek dokumentálva vannak.
96. A szerepkörökhöz kapcsolódó jogosultságok dokumentálva vannak?
97. Milyen kockázatokkal jár a hozzáférési jogok megsértése, és ez hogyan befolyásolhatja a rendszer különböző komponenseit?
98. A tulajdonos manipulálhatja a szerződésen belül a tokeneket és az ETH-t?
99. Hogyan van beállítva az oracle (Oracle) cím és mi a folyamat mögötte? Vannak tartalék orákulumok a biztonsági mentéshez?
100. Hogyan vannak hasonló funkciók más projektekben megvalósítva, figyelembe vették-e a legjobb gyakorlatokat?

Ez az ellenőrzőlista segít abban, hogy a Solidity okosszerződések alapos biztonsági auditját elvégezze. A kritikus szempontok széles skáláját öleli fel a kódban és a kapcsolódó rendszerekben rejlő potenciális sebezhetőségek és kockázatok azonosítása és mérséklése érdekében.

 

Reméljük, hogy ezek a példák segítettek jobban megérteni az okosszerződések auditálásának módszertanát.

 

Mivel a blokkláncban minden információ nyílt (feltéve persze, hogy a szerződés forráskódját ellenőrzik), ezzel a tudással felvértezve önállóan is tanulmányozhatja az okosszerződéseket és azonosíthatja a különböző átverési rendszereket.

Mivel azonban már mindent megtettünk Ön helyett! Iratkozzon fel prémium előfizetésre, és hozzáférhet az intelligens szerződések jellemzőire vonatkozó exkluzív szűrőkhöz és friss elemzésekhez. Növelje az esélyét, hogy sikeresen fektessen be nyereséges tokenekbe.

Regards, Lotus Market team.

All posts