Isekontrollivad arukad lepingud koos ChatGPT-ga

Oskuslepingute auditeerimisel on vaja käsitleda mitmeid küsimusi, et tagada koodi turvalisus. Need küsimused hõlmavad erinevaid aspekte, sealhulgas juurdepääsukontrolli, varahaldust, andmehaldust, eeldusi, sõltuvusi ja turvalisuse kontrollnimekirju. Järgnevalt esitame üksikasjaliku kontrollnimekirja ja juhised ChatGPT päringute jaoks, et juhendada teid nutilepingute auditeerimise protsessis.

Kui soovite ise uurida nutilepingut haavatavuste ja varjatud pettustehnikate suhtes, on esimene samm õigesti koostatud ChatGPT päring.

Huvitav päring ChatGPT jaoks oleks järgmine käsk:

Täielik nimekiri kõigist probleemidest ja haavatavustest järgmises nutilepingus. Kirjeldage probleeme ja võimalikke haavatavusi üksikasjalikult. Esitage iga haavatavuse kohta üks ekspluateerimisstsenaarium. Väljastada kehtiv tabelina markdown-vormingus objektide loeteluga, millel on veerud "description", "action", "severity", "actors", "scenario", "type" ja "line". 'type', kus võib olla 'usability', 'vulnerability', 'optimization' või 'suggestion'. 'actors' on asjaomaste osalejate loetelu. "raskusaste" võib olla "madal", "keskmine" või "kõrge". 'row' on probleemi rea number. Veenduge, et kõik tabeli väljad on täidetud.

Kasutage seejärel järgmisi küsimusi, et uurida nutilepingut põhjalikumalt.

Kasutamise stsenaariumid:

1. Kes on süsteemis osalejad?


2. Mis tegevusi on süsteemil?


3. Millised on süsteemi piirangud?


4. Millised on võimalikud viisid süsteemi murdmiseks?


5. Milliseid kaitsemeetmeid kasutatakse rünnakute tõrjumiseks?


6. Kirjeldage piirangute põhjal iga funktsiooni olekumuutusi.


7. Andke teavet kasutatud Solidity ja DeFi mallide kohta.


8. Kirjutage süsteemi kohta käiva teabe põhjal positiivsed ja negatiivsed aksioomid.


9. Nimetage võimalusi koodi optimeerimiseks ja muutmiseks, et muuta see usaldusväärsemaks (koodilõikudega).


10. Loetlege koodis kasutatud varjatud pettusemeetodid (koodilõikudega).

Tipp: Andmete visuaalne kujutamine annab sageli selgema arusaama süsteemi toimimisest. ChatGPT-ga töötades on soovitatav nõuda väljundandmete visualiseerimist, näiteks oleku muutuste visualiseerimist ASCII-tähemärkide diagrammide kujul. Kuigi kõik visualiseeringud ei pruugi olla mõistlikud, võivad mõned neist anda väga väärtusliku ülevaate aruka lepingu toimimisest.

Tõepoolest, kuigi ChatGPT ei saa asendada inimese audiitorit, täiendab see märkimisväärselt auditeerimisprotsessi, andes selgema arusaama protokolli oleku üleminekutest, piirangutest, invariantsidest ja ühilduvusest. See tööriist on eriti tõhus protokolli oleku üleminekute ja piirangute mõistmiseks.

Nipp: Enne auditi alustamist võib auditeeritava protokolli dokumentatsiooni esitamine juturobotile oluliselt parandada vastuste täpsust ja asjakohasust. Mainige lihtsalt: "See on dokumentatsioon, mis annab parima konteksti 'protokolli_nimi' kohta, mida ma auditeerin," ja sisestage dokument."

Võib öelda, et ChatGPT on võimas assistent audiitoritele, pakkudes struktureeritud ja põhjalikku lähenemist nutilepingute auditeerimiseks. Siiski tuleb meeles pidada, et ChatGTP (ja sarnased teenused) on lihtsalt tõenäosustega töötava masinanalüüsi keerulised tõlgendused, mistõttu see tekitab sageli vigu ja ebatäpsusi. Sellest tulenevalt ei saa ChatGPT tulemusele täielikult tugineda - see on vaid hea vahend õigetes kätes ja "lähtepunkt" nutilepingute uurimisel.

Sellepärast tuleks võimalike riskide eest kaitsmiseks uurida nutilepinguid hoolikamalt võimalike haavatavuste ja pettuslike skeemide suhtes.

Kuidas teha põhjalik nutilepingute audit? Top 100 päringut ChatGPT-le

Ülepoolt oleme käsitlenud üldist päringut (prompt) ChatGPT-le, millest saab alustada nutilepingu analüüsi. Kuid loomulikult ei piirdu üksikasjalik analüüs vaid sissejuhatava päringuga.

Kelmid täiustavad pidevalt oma taktikat, seega peate olema paljudes aspektides informeeritud ja ettevaatlik - need on olulised strateegiad, et kaitsta oma tokeniinvesteeringut.

Vaatame üle nimekirja 100-st päringust, mis annab teile professionaalse lähenemise nutilepingu auditi tegemiseks:

1. Kas kood kompileeritakse edukalt?
2. Millist Solidity versiooni kasutatakse koodis? Kas see on praegune stabiilne versioon?
3. Kas on olemas selged kommentaarid, mis selgitavad funktsioonide ja muutujate otstarvet?
4. Kas lepingus on kasutatud "Omandatav" skeemi? Kui jah, siis milliste funktsioonide puhul?
5. Kas olekumuutujad on korrektselt eraldatud nähtavuse modifikaatorite abil?
6. Kas sündmusi kasutatakse nõuetekohaseks logimiseks?
7. Kas kasutajasõbralikud veateated on esitatud?
8. Kas madala taseme kutsete tagastusväärtust kontrollitakse?
9. Kas on olemas stsenaariumid, kus omanik võib end autoriseerida, mis võivad viia vaiba tõmbamiseni?
10. Kellel on kontroll privilegeeritud kontode üle ja millised on kontrollimehhanismid?
11. Millised juhtimismehhanismid on lepingus olemas ja kas juhtimine on täielikult avatud või piiratud?
12. Kas süsteemis kasutatakse muid lepinguid ja milliseid ülesandeid need täidavad (nt asendusleping)?
13. Kas on olemas aja lukustusmehhanism ja kas sellest saab mööda minna?
14. Kas on olemas piisav dokumentatsioon?
15. Kas koodis on võimalikke haavatavusi DoS- või reentrancy-rünnakute suhtes?
16. Kas kõik funktsioonid on sisemised, välja arvatud need, mis on selgesõnaliselt nõutavad avalikud/välised?
17. Aritmeetilised ülevoolud/allavoolud matemaatilistes operatsioonides puuduvad?
18. Kas kasutatakse turvalist OpenZeppelini raamatukogu?
19. Eetrit või märke ei saa kogemata saata null-aadressile (0x0)?
20. Tingimusi kontrollitakse enne operatsioone ja oleku muutusi?
21. Kas olek on määratud enne tegevuste sooritamist ja nende täitmise ajal?
22. Kas kasutatakse kaitset tagasituleku (reentry) rünnakute vastu (A kutsub B kutsub A)?
23. Kas ERC20 liides on nõuetekohaselt rakendatud?
24. Kas modifikaatorit kasutatakse mitmes kohas ainult siis, kui see on tõesti vajalik?
25. Kas kõik tüübid on selgesõnaliselt määratud (nt uint256 kasutatakse uint asemel)?
26. Kas kõik meetodid ja tsüklid jäävad maksimaalse lubatud gaasi piirnormi piiresse?
27. Konstruktoris ei ole mittevajalikke initsialiseerimisi (pea meeles, et vaikeväärtused on määratud)?
28. Testi katvus on täielik: testitakse iga nutika lepingu meetodit ja kõiki võimalikke sisendandmete tüüpe?
29. Kas fuzz-testi on tehtud juhuslikke sisendeid kasutades?
30. Kas kõik võimalikud seisundid, milles leping võib olla, on testitud?
31. Eetri ja žetoonide vaikimisi kogused on määratud ühikutes wei?
32. Kas crowdsale'i lõpublokk/-aeg tuleb pärast algblokki/-aega (kauplemise alustamine/võimaldamine)?
33. Kas crowdsale-tokenide vahetuskurss/konversioonikurss on õigesti seatud?
34. Kas on kehtestatud pehme/kõrge crowdsale'i limiit?
35. Kas minimaalne/maksimaalne lubatud panus crowdsale on kehtestatud ja testitud?
36. Kas crowdsale whitelisting funktsionaalsust on testitud?
37. Kas crowdsale'i tagasimakse loogika on kontrollitud?
38. Kas crowdsale'is osalejad saavad proportsionaalse arvu žetoneid või saavad nad nõuda oma panust?
39. Kas rahvamüügi iga etapi (nt eelmüük, avalik müük) kestus on nõuetekohaselt konfigureeritud?
40. Kas selles on täpsustatud, milliseid funktsioone peaks kontrollima ainult omanik (nt rahvahulga müügi peatamine, rahvahulga müügi teise etappi üleminek, žetoonide jaotamise võimaldamine jne)?
41. Kas crowdsale vesting (omandamise) loogika on kontrollitud?
42. Crowdsale'il on turvarežiim, mis omaniku poolt aktiveerituna piirab funktsioonikõnesid ja sisaldab tagasimaksefunktsiooni?
43. Crowdsale'il on tagavarafunktsioon, kui see on mõistlik.
44. There is a fallback feature for crowdsale if it is reasonable.aHave the imported libraries been checked in advance and do they not contain unwanted parts that could be replaced in future versions and used for malicious purposes?
45. Tokeni ülekandemeetodid (ülekanne) pakitud nõuda?
46. Kas require ja assert on õigesti kasutatud? Meetodit assert kasutatakse ainult selliste asjade puhul, mis ei tohiks kunagi juhtuda, tavaliselt kasutatakse seda oleku kontrollimiseks pärast muudatuste tegemist.
47. Kas on olemas kaitse rekursiivsete kõnede rünnakute vastu?
48. Kas sisendis olevate suvaliste stringide pikkused on piiratud?
49. Vältige võimaluse korral massiivi kasutamist ja kasutage selle asemel kaardistusi?
50. Kas plokkide hash'e ei kasutata juhuslike väärtuste käitlemiseks (kaevurid võivad seda mõjutada)?
51. Ei kasuta tx.origin kuskil?
52. Array elemendid nihkuvad elemendi kustutamisel allapoole, et ei jääks lünki?
53. Kas viskamise asemel kasutatakse revert?
54. Funktsioonid lõpevad kohe, kui tingimused ei ole täidetud?
55. Kas kompilaatori hoiatused on lahendatud?
56. Kas arvutustes kasutatakse SafeMathi raamatukogu?
57. Kas mõnda mälupesa (mälupesa) loetakse rohkem kui üks kord?
58. Kas mõnda mälupesa (mälupesa) loetakse rohkem kui üks kord?a Kas kasutatakse piiramatuid silmuseid/ridasid, mis võivad põhjustada DoS-i?
59. Kas block.timestamp kasutatakse ainult pikkade ajavahemike puhul?
60. Ei kasuta blokki.number kulunud aja arvutamiseks?
61. Kas delegatecall-kõneid välditakse, eriti väliste (isegi kui need on usaldusväärsed) lepingute puhul?
62. Kas massiivi pikkust ei uuendata selle üle itereerimise ajal?
63. Kas allkirjad on nonce'i ja block.chainid'iga kordamise eest kaitstud?
64. Veenduge, et kõik allkirjad kasutavad EIP-712?
65. Abi.encodePacked() väljundit ei tohiks hajutada, kui kasutatakse rohkem kui 2 dünaamilist tüüpi. Üldiselt on parem kasutada abi.encode().
66. Kontrollige hoolikalt koostekoodi sisestusi.
67. Vältige ebapiisavat gaasitarbimist (gas griefing).
68. Kas kõik privaatsed andmed on tõesti privaatsed?
69. Struktuuri/massiivi uuendamine mälus (mälu) ei muuda seda mälus (staadiumis)?
70. Kas lavalised muutujad jäävad varju?
71. Kas muutuja väärtuse arvutamine jooksvalt on odavam kui selle salvestamine?
72. Kas kõiki olekumuutujaid loetakse õigest lepingust (master vs. kloon)?
73. Kas võrdlusoperaatoreid (>, <, >=, <=) kasutatakse õigesti, eriti selleks, et vältida vigu, mis ei ole üks-ühele?
74. Kas loogilisi operaatoreid (==, !=, &&, ||, !) kasutatakse õigesti, eriti selleks, et vältida vigu, mis ei ole üks ühele?
75. Kas korrutamine toimub alati enne jagamist (välja arvatud juhul, kui korrutamine võib üle voolata)?
76. Kas maagilised numbrid on asendatud konstandiga, millel on intuitiivne nimi?
77. Kui ETH-vastuvõtjal on tagasilöögifunktsioon (fallback ), mida saab tagasi pöörata, kas see võib põhjustada DoSi?
78. Kas kasutatakse SafeERC20 standardit ja kas tagastusväärtusi kontrollitakse turvaliselt?
79. Kas eeldatakse, et msg.sender on alati asjaomane kasutaja?
80. Kas tx.origin'i ei kasutata autoriseerimiseks?
81. Kas address.transfer() või address.send() ei kasutata .call.value() asemel?
82. Kui kasutate madala taseme kõnesid, veenduge, et leping on enne kõnet olemas.
83. Kas Solidity süntaksi asemel kasutatakse chainidile või lepingukoodile/suurusele/hashile juurdepääsuks assemblerikoodi?
84. Kas võtmesõna delete kasutatakse muutuja nullväärtuse (0, false, "" , jne) määramisel?
85. Loogilistele operaatoritele/võrdlustele (&&/||/>=/==/ jne) edastatud avaldistel ei tohi olla kõrvalmõjusid.
86. Kui tegemist on mitme aadressiga, küsige endalt, mis juhtub, kui need on samad?
87. Kui hästi on kood dokumenteeritud? Kas kõikjal, kus kasutatakse mittestandardset koodi, on esitatud kommentaarid ja näited?
88. Kui kasutatakse väliskõnet, siis veenduge, et väline lepinguline kõne on tõesti vajalik?
89. Kas väliskõne tulemust kontrollitakse ja kas vigu käsitletakse?
90. Mis juhtub, kui External Call kasutab kogu etteantud gaasi?
91. Kui External Call kutsub konkreetset funktsiooni, veenduge, et see funktsioon on tegelikult olemas (fantoomfunktsioonid).
92. Veenduge, et modifikaatorites (modifikaatorites) ei kasutata väliskõnesid.
93. Kas sündmused väljastatakse iga funktsiooni kohta, mis muudab salvestusruumi?
94. Kontrollige oma eeldusi selle kohta, mida välised lepingud, mida kasutatakse põhiliselt, teevad ja tagastavad.
95. Jälgige märke, mis kasutavad liiga palju või liiga vähe kümnendkohti. Veenduge, et maksimaalsed ja minimaalsed toetatavad väärtused on dokumenteeritud.
96. Kas rollidega seotud volitused on dokumenteeritud?
97. Millised on riskid, kui juurdepääsuõigusi rikutakse, ja kuidas see võib mõjutada süsteemi erinevaid komponente?
98. Kas omanik saab lepingu raames žetoonidega ja ETH-dega manipuleerida?
99. Kuidas on oracle (Oracle) aadressi määramine ja milline on selle protsess? Kas varukoopia jaoks on olemas varuoraaklid?
100. Kuidas on sarnaseid funktsioone rakendatud teistes projektides, kas on arvesse võetud parimaid tavasid?

See kontrollnimekiri aitab teil tagada Solidity nutilepingute põhjaliku turvaauditi läbiviimise. See hõlmab paljusid kriitilisi aspekte, et tuvastada ja leevendada võimalikke haavatavusi ja riske koodis ja sellega seotud süsteemides.

 

Me loodame, et need näited aitasid teil paremini mõista nutilepingute auditi metoodikat.

 

Kui kogu teave plokiahelas on avatud (eeldusel muidugi, et lepingu lähtekood on kontrollitud), saate nende teadmistega relvastatud nutilepinguid iseseisvalt uurida ja erinevaid pettuse skeeme tuvastada.

Me oleme aga selle kõik juba teie eest ära teinud! Registreeruge lisatellimuseks ja saate juurdepääsu eksklusiivsetele filtritele nutilepingute funktsioonide ja värske analüüsi kohta. Suurendage oma võimalusi investeerida edukalt kasumlikesse tokenitesse.

Regards, Lotus Market team.

All posts