Viedo līgumu pašauditēšana ar ChatGPT

Veicot viedo līgumu revīziju, ir jāaptver plašs jautājumu loks, lai nodrošinātu koda drošību. Šie jautājumi aptver dažādus aspektus, tostarp piekļuves kontroli, aktīvu pārvaldību, datu pārvaldību, pieņēmumus, atkarības un drošības pārbaudes sarakstus. Zemāk piedāvājam detalizētu kontrolsarakstu un norādījumus par ChatGPT vaicājumiem, kas palīdzēs jums gudro līgumu audita procesā.

Ja vēlaties paši izpētīt kādu gudro līgumu, lai noteiktu, vai tajā nav ievainojamību un slēptu krāpšanas paņēmienu, pirmais solis ir pareizi sagatavots ChatGPT vaicājums.

Pierocīgs ChatGPT vaicājums būtu šāda komanda:

Sniedziet visaptverošu sarakstu ar visām problēmām un ievainojamībām šajā gudrajā līgumā. Detalizēti aprakstiet problēmas un iespējamās ievainojamības. Sniedziet vienu izmantošanas scenāriju katrai ievainojamībai. Izvadiet kā derīgu tabulu markdown formātā ar objektu sarakstu, katram no tiem norādot kolonnas "apraksts", "darbība", "nopietnība", "dalībnieki", "scenārijs", "tips" un "rinda". "tips", kur var būt "lietojamība", "ievainojamība", "optimizācija" vai "ieteikums". "actors" ir iesaistīto dalībnieku saraksts. "nopietnība" var būt "zema", "vidēja" vai "augsta". "rinda" ir problēmas rindas numurs. Pārliecinieties, ka visi tabulas lauki ir aizpildīti.

Pēc tam izmantojiet turpmāk uzdotos jautājumus, lai padziļināti izpētītu viedo līgumu.

Izmantošanas scenāriji:

1. Kādi ir sistēmas dalībnieki?


2. Kādas darbības ir sistēmai?


3. Kādi ir sistēmas ierobežojumi?


4. Kādi ir iespējamie veidi, kā sistēmu uzlauzt?


5. Kāda aizsardzība tiek izmantota, lai novērstu uzbrukumus?


6. Aprakstiet, pamatojoties uz ierobežojumiem, katras funkcijas stāvokļa izmaiņas.


7. Izklāstiet informāciju par izmantotajiem Solidity un DeFi šabloniem.


8. Sastādiet pozitīvas un negatīvas aksiomas, pamatojoties uz informāciju par sistēmu.


9. Nosauciet veidus, kā optimizēt un modificēt kodu, lai padarītu to uzticamāku (ar koda fragmentiem).


10. Nosaukt kodā izmantotās slēptās krāpšanas metodes (ar koda fragmentiem).

Padoms: Datu vizuālais attēlojums bieži sniedz skaidrāku izpratni par sistēmas darbību. Strādājot ar ChatGPT, ieteicams pieprasīt izejas datu vizualizāciju, piemēram, stāvokļa izmaiņas ASCII rakstzīmju diagrammu veidā. Lai gan ne visām vizualizācijām var būt jēga, dažas no tām var sniegt ļoti vērtīgu ieskatu viedā līguma darbībā.

Patiesībā, lai gan ChatGPT nevar aizstāt cilvēku auditoru, tā būtiski papildina audita procesu, nodrošinot skaidrāku izpratni par protokola stāvokļu pārejām, ierobežojumiem, invariantiem un savietojamību. Šis rīks ir īpaši efektīvs, lai izprastu protokola stāvokļa pārejas un ierobežojumus.

Padoms: Pirms audita uzsākšanas, nodrošinot čatbotu ar auditējamā protokola dokumentāciju, var ievērojami uzlabot atbilžu precizitāti un atbilstību. Vienkārši miniet: "Šī ir dokumentācija, kas sniedz vislabāko kontekstu attiecībā uz "protokola_nosaukumu", kuru es auditēju," un ievietojiet dokumentu.

Var teikt, ka ChatGPT ir spēcīgs palīgs auditoriem, kas nodrošina strukturētu un padziļinātu pieeju viedo līgumu auditēšanai. Tomēr jāatceras, ka ChatGTP (un līdzīgi pakalpojumi) ir tikai sarežģītas mašīniskās analīzes interpretācijas, kas strādā ar varbūtībām, tāpēc bieži vien rada kļūdas un neprecizitātes. Attiecīgi uz ChatGPT rezultātiem nevar pilnībā paļauties - tas ir tikai labs rīks pareizās rokās un "sākumpunkts" viedo līgumu izpētē.

Tāpēc, lai pasargātu sevi no iespējamiem riskiem, viedie līgumi ir jāizpēta rūpīgāk, meklējot iespējamās ievainojamības un krāpnieciskas shēmas.

Kā veikt padziļinātu viedo līgumu auditu? Top 100 pieprasījumi ChatGPT

Apskatīts vispārīgs pieprasījums (pamudinājums) ChatGPT, no kura var sākt viedā līguma analīzi. Taču, protams, padziļināta analīze neaprobežojas tikai ar ievada uzvedni.

Pārkāpēji nepārtraukti uzlabo savu taktiku, tāpēc jums ir jābūt informētam un piesardzīgam daudzos aspektos - tās ir būtiskas stratēģijas, lai aizsargātu savus žetonu ieguldījumus.

Apskatīsim 100 svarīgāko vaicājumu sarakstu, kas ļaus jums profesionāli veikt viedo līgumu auditu:

1. Vai kods ir veiksmīgi kompilēts?
2. Kāda Solidity versija ir izmantota kodā? Vai tā ir pašreizējā stabilā versija?
3. Vai ir skaidri komentāri, kas izskaidro funkciju un mainīgo mērķi?
4. Vai līgumā ir izmantota "Ownable" shēma? Ja jā, tad kurām funkcijām?
5. Vai stāvokļa mainīgie ir pareizi piešķirti, izmantojot redzamības modifikatorus?
6. Vai tiek izmantoti notikumi pareizai žurnālu reģistrēšanai?
7. Vai tiek sniegti lietotājam draudzīgi kļūdu ziņojumi?
8. Vai tiek pārbaudīta zema līmeņa izsaukumu atgriešanas vērtība?
9. Vai ir scenāriji, kuros īpašnieks var pilnvarot sevi, kas varētu novest pie paklāja vilkšanas?
10. Kam ir kontrole pār priviliģētajiem kontiem un kādi ir kontroles mehānismi?
11. Kādi pārvaldības mehānismi ir līgumā, un vai pārvaldība ir pilnībā atvērta vai ierobežota?
12. Vai sistēmā tiek izmantoti citi līgumi un kādas funkcijas tie pilda (piemēram, pilnvarotā līgums)?
13. Vai ir laika bloķēšanas mehānisms un vai to var apiet?
14. Vai ir pieejama atbilstoša dokumentācija?
15. Vai kodā ir iespējamas DoS vai reentrancesijas uzbrukumu ievainojamības?
16. Visas funkcijas ir iekšējas, izņemot tās, kurām ir skaidri noteikts, ka tās ir publiskas/ārējas?
17. Matemātiskajās operācijās nav aritmētisko pārplūžu/nepilnību?
18. Vai tiek izmantota droša OpenZeppelin bibliotēka?
19. Eteri vai žetonus nevar nejauši nosūtīt uz nulles adresi (0x0)?
20. Uzdevumi tiek pārbaudīti ar require pirms operācijām un stāvokļa izmaiņām?
21. Vai stāvoklis tiek iestatīts pirms darbību izpildes un to izpildes laikā?
22. Vai tiek izmantota aizsardzība pret atkārtotiem (reentry) uzbrukumiem (A sauc B sauc A)?
23. Vai ERC20 saskarne ir pareizi īstenota?
24. Vai modifikators tiek izmantots vairākās vietās tikai tad, ja tas patiešām ir nepieciešams?
25. Vai visi tipi ir skaidri noteikti (piemēram, uint256 vietā tiek izmantots uint)?
26. Vai visas metodes un cikli nepārsniedz maksimālo pieļaujamo gāzes limitu?
27. Konstruktorā nav nevajadzīgu inicializāciju (atcerieties, ka ir iestatītas noklusējuma vērtības)?
28. Testu pārklājums ir pilnīgs: ir pārbaudīta katra viedā līguma metode un visi iespējamie ievades datu tipi?
29. Vai ir veikta fuzz testēšana, izmantojot nejaušus ievades datus?
30. Vai ir pārbaudīti visi iespējamie stāvokļi, kuros var atrasties līgums?
31. Lai eteru un žetonu noklusējuma summas ir norādītas wei vienībās?
32. Vai pūļa pārdošanas beigu bloks/laiks ir pēc sākuma bloka/laika (tirdzniecības sākšanas/ieslēgšanas)?
33. Vai pūļa pārdošanas žetonu maiņas/konversijas kurss ir iestatīts pareizi?
34. Vai ir iestatīts mīkstais/cietais pūļa pārdošanas limits?
35. Vai ir iestatīts un pārbaudīts minimālais/marksimālais pieļaujamais ieguldījums pūļa pārdošanā?
36. Vai ir pārbaudīta pūļa pārdošanas baltā saraksta funkcionalitāte?
37. Vai ir pārbaudīta pūļa pārdošanas atmaksas loģika?
38. Vai pūļa pārdošanas dalībnieki saņem proporcionālu skaitu žetonu vai viņi var pieprasīt savu ieguldījumu?
39. Vai katra pūļa pārdošanas posma ilgums (piem, iepriekšēja pārdošana, publiskā pārdošana) ir pareizi konfigurēts?
40. Vai ir norādīts, kuras funkcijas drīkst kontrolēt tikai īpašnieks (piem, apturēt pūļa pārdošanu, pāriet uz citu pūļa pārdošanas posmu, ieslēgt žetonu izplatīšanu u. c.)?
41. Vai ir pārbaudīta pūļa pārdošanas tiesību piešķiršanas (tiesību piešķiršanas) loģika?
42. Vai pūļa pārdošanai ir drošais režīms, kas, īpašniekam to ieslēdzot, ierobežo funkciju izsaukumus un ietver atmaksas funkciju?
43. Crowdsale ir rezerves funkcija, ja tai ir saprātīga jēga.
44. Vai importētās bibliotēkas ir iepriekš pārbaudītas un nesatur nevēlamas daļas, kuras var tikt aizstātas nākamajās versijās un kuras varētu tikt izmantotas ļaunprātīgiem mērķiem?
45. Vai toenu pārneses metodes (transfer) ir ietītas require?
46. Vai require un assert ir izmantotas pareizi? Assert metodi izmanto tikai lietām, kurām nekad nevajadzētu notikt, parasti to izmanto, lai pārbaudītu stāvokli pēc izmaiņu veikšanas.
47. Vai ir aizsardzība pret rekursīvo izsaukumu uzbrukumiem?
48. Vai ir ierobežots patvaļīgu ieejas virkņu garums?
49. Ja iespējams izvairīties no masīvu izmantošanas un tā vietā izmantot kartēšanu?
50. Vai bloka hashe netiek izmantoti, lai apstrādātu nejaušas vērtības (to var ietekmēt kalnrači)?
51. Visur netiek izmantots tx.origin?
52. Matula elementi tiek nobīdīti uz leju, kad elements tiek dzēsts, lai neatstātu atstarpes?
53. Vai throw vietā tiek izmantots revert?
54. Funkcijas nekavējoties beidzas, ja nosacījumi netiek izpildīti?
55. Vai ir novērsti kompilatora brīdinājumi?
56. Vai aprēķinos tiek izmantota SafeMath bibliotēka?
57. Vai kāds atmiņas slots (glabāšanas slots) tiek nolasīts vairāk nekā vienu reizi?
58. Vai tiek izmantoti neierobežoti cikli/plaukti, kas varētu izraisīt DoS?
59. Vai block.timestamp tiek izmantots tikai gariem intervāliem?
60. Vai netiek izmantots block. number, lai aprēķinātu pagājušo laiku?
61. Vai ir jāizvairās no delegatecall izsaukuma, jo īpaši ārējiem (pat ja uzticamiem) līgumiem?
62. Vai masīva garums netiek atjaunināts, to iterējot?
63. Vai paraksti ir aizsargāti pret atkārtojumiem ar nonce un block.chainid?
64. Uliecinieties, ka visi paraksti izmanto EIP-712?
65. Abi.encodePacked() rezultātu nevajadzētu hešēt, ja tiek izmantoti vairāk nekā 2 dinamiskie tipi. Kopumā vēlams izmantot abi.encode().
66. Urūpīgi pārbaudiet asamblejas koda iestarpinājumus.
67. Izvairieties no nepietiekama gāzes patēriņa (gas griefing).
68. Vai visi privātie dati patiešām ir privāti?
69. Vai struktūras/plaknes atjaunināšana atmiņā (atmiņā) nemainīs to glabāšanā (stadijā)?
70. Vai stadijas mainīgie ir pārtēnoti?
71. Vai mainīgā vērtības aprēķināšana lidojumā ir lētāka nekā tā glabāšana?
72. Vai visi stāvokļa mainīgie tiek nolasīti no pareizā līguma (master vs. clone)?
73. Vai salīdzināšanas operatori (>, <, >=, <=) tiek lietoti pareizi, īpaši, lai novērstu kļūdas, kas nav pa vienai?
74. Vai logiskie operatori (==, ! =, &&, ||, !) tiek lietoti pareizi, jo īpaši, lai novērstu kļūdas, kas nav pa vienai?
75. Vai reizināšana vienmēr tiek veikta pirms dalīšanas (ja vien reizināšana var pārplūst)?
76. Vai maģiskie skaitļi tiek aizstāti ar konstantu ar intuitīvu nosaukumu?
77. Ja ETH saņēmējam ir atgriezeniskā (fallback ) funkcija, kuru var atgriezt, vai tas var izraisīt DoS?
78. Vai tiek izmantots SafeERC20 standarts un vai atgrieztās vērtības tiek pārbaudītas drošā veidā?
79. Vai tiek pieņemts, ka msg. sūtītājs vienmēr ir attiecīgais lietotājs?
80. Vai autorizācijai netiek izmantots .origin?
81. Vai .call.value() vietā netiek izmantots .address.transfer() vai .address.send()?
82. Vai, izmantojot zema līmeņa izsaukumus, pārliecinieties, ka pirms izsaukuma pastāv līgums.
83. Vai piekļuvei chainid vai līguma kodam/izmēram/hash tiek izmantots asamblejas kods, nevis Solidity sintakse?
84. Vai, iestatot mainīgajam nulles vērtību (0, false, "" utt.), tiek izmantots atslēgvārds delete?
85. Logiskajiem operatoriem/ salīdzinājumiem (&&/|||/>=/==/ utt.) nodotajiem izteicieniem nedrīkst būt blakusparādību.
86. Kad strādājot ar vairākām adresēm, vaicājiet sev, kas notiek, ja tās ir vienādas?
87. Kā labi ir dokumentēts kods? Vai ir sniegti komentāri un piemēri visur, kur tiek izmantots nestandarta kods?
88. Ja tiek izmantots ārējais izsaukums, pārliecinieties, ka ārējā līguma izsaukums patiešām ir nepieciešams?
89. Vai tiek pārbaudīts ārējā izsaukuma rezultāts un vai tiek apstrādātas kļūdas?
90. Kas notiek, ja ārējais izsaukums izmanto visu sniegto gāzi?
91. Ja ārējais izsaukums izsauc konkrētu funkciju, pārliecinieties, vai šī funkcija patiešām pastāv (fiktīvas funkcijas).
92. Pārliecinieties, ka modifikatoros netiek izmantoti ārējie izsaukumi (modifikatori)
93. Vai notikumi tiek izdoti katrai funkcijai, kas modificē krātuvi?
94. Pārbaudiet savus pieņēmumus par to, ko dara un ko atdod galvenajā izmantotie ārējie līgumi.
95. Urvērsiet uzmanību, vai žetonos netiek izmantoti pārāk daudz vai pārāk maz decimālskaitļu. Pārliecinieties, ka maksimālās un minimālās atbalstītās vērtības ir dokumentētas.
96. Vai ir dokumentētas ar lomām saistītās pilnvaras?
97. Kādi ir riski, ja tiek pārkāptas piekļuves tiesības, un kā tas var ietekmēt dažādus sistēmas komponentus?
98. Vai īpašnieks var manipulēt ar žetoniem un ETH līguma ietvaros?
99. Kā tiek noteikta Oracle (Oracle) adrese un kāds ir tās process? Vai ir rezerves orakļi rezerves kopijām?
100. Kā līdzīgas funkcijas ir īstenotas citos projektos, vai ir ņemta vērā labākā prakse?

Šis kontrolsaraksts palīdzēs jums nodrošināt, ka veicat rūpīgu Solidity viedo līgumu drošības auditu. Tas aptver plašu kritisko aspektu klāstu, lai identificētu un mazinātu iespējamās neaizsargātības un riskus kodā un saistītajās sistēmās.

 

Mēs ceram, ka šie piemēri ir palīdzējuši jums labāk izprast viedo līgumu audita metodoloģiju.

 

Tā kā visa informācija blokķēdē ir atklāta (protams, ar nosacījumu, ka ir pārbaudīts līguma pirmkods), bruņojies ar šīm zināšanām, jūs varat patstāvīgi izpētīt viedos līgumus un identificēt dažādas krāpšanas shēmas.

Vis to jau esam izdarījuši jūsu vietā! Pierakstieties uz premium abonementu un iegūstiet piekļuvi ekskluzīviem viedo līgumu funkciju filtriem un svaigai analīzei. Palielini savas izredzes veiksmīgi investēt ienesīgos žetonos.

Regards, Lotus Market komanda.

All posts