Contracte inteligente cu autoaudit cu ChatGPT

La auditarea contractelor inteligente, o gamă largă de aspecte trebuie să fie acoperite pentru a se asigura că codul este sigur. Aceste întrebări acoperă diverse aspecte, inclusiv controlul accesului, gestionarea activelor, gestionarea datelor, ipoteze, dependențe și liste de verificare a securității. Mai jos oferim o listă de verificare detaliată și instrucțiuni pentru interogările ChatGPT pentru a vă ghida în procesul de auditare a contractelor inteligente.

Dacă doriți să investigați singur un contract inteligent pentru vulnerabilități și tehnici ascunse de înșelăciune, primul pas este o interogare ChatGPT corect elaborată.

O interogare utilă pentru ChatGPT ar fi următoarea comandă:

Furnizați o listă completă a tuturor problemelor și vulnerabilităților din următorul contract inteligent. Descrieți în detaliu problemele și posibilele vulnerabilități. Furnizați un scenariu de exploatare pentru fiecare vulnerabilitate. Ieșiți ca un tabel valid în format markdown cu o listă de obiecte, fiecare cu coloanele 'description', 'action', 'severity', 'actors', 'scenario', 'type' și 'line'. "type" unde poate fi "usability", "vulnerability", "optimization" sau "suggestion". "actors" este o listă a actorilor implicați. "severity" poate fi "low", "medium" sau "high". "row" este numărul de rând al problemei. Asigurați-vă că toate câmpurile din tabel sunt completate.

Apoi utilizați următoarele întrebări pentru a explora contractul inteligent mai în profunzime.

Scenarii de utilizare:

1. Cine sunt actorii din sistem?


2. Ce acțiuni are sistemul?


3. Care sunt limitările sistemului?


4. Care sunt unele modalități potențiale de a sparge sistemul?


5. Ce mijloace de apărare sunt folosite pentru a contracara atacurile?


6. Descrieți, pe baza constrângerilor, schimbările de stare ale fiecărei funcții.


7. Furnizați informații despre modelele Solidity și DeFi utilizate.


8. Scrieți axiome pozitive și negative pe baza informațiilor despre sistem.


9. Enumerați modalități de optimizare și modificare a codului pentru a-l face mai fiabil (cu fragmente de cod).


10. Listați metodele de înșelăciune ascunse utilizate în cod (cu fragmente de cod).

Sfat: Reprezentarea vizuală a datelor oferă adesea o înțelegere mai clară a funcționării sistemului. Atunci când lucrați cu ChatGPT, este recomandat să solicitați vizualizări ale datelor de ieșire, cum ar fi modificările de stare sub formă de diagrame de caractere ASCII. De fapt, deși ChatGPT nu poate înlocui un auditor uman, acesta completează în mod semnificativ procesul de audit prin furnizarea unei înțelegeri mai clare a tranzițiilor de stare ale protocolului, a constrângerilor, invarianților și compatibilității. Acest instrument este deosebit de eficient pentru înțelegerea tranzițiilor de stare și a constrângerilor protocolului.

Sfat: Înainte de a începe un audit, furnizarea către chatbot a documentației privind protocolul auditat poate îmbunătăți considerabil acuratețea și relevanța răspunsurilor. Este suficient să menționați: "Aceasta este documentația care oferă cel mai bun context pentru "protocol_name" pe care îl auditez" și să introduceți documentul.

Se poate spune că ChatGPT este un asistent puternic pentru auditori, oferind o abordare structurată și aprofundată a auditării contractelor inteligente. Cu toate acestea, trebuie avut în vedere faptul că ChatGPT (și serviciile similare) sunt doar interpretări complexe ale analizei automate care lucrează cu probabilități, astfel încât produce adesea erori și inexactități. În consecință, rezultatul ChatGPT nu poate fi pe deplin fiabil - este doar un instrument bun în mâinile potrivite și un "punct de plecare" în cercetarea contractelor inteligente.

De aceea, pentru a vă proteja de eventualele riscuri, contractele inteligente ar trebui examinate mai atent pentru a depista eventualele vulnerabilități și scheme frauduloase.

Cum să efectuați un audit aprofundat al contractelor inteligente? Top 100 de solicitări către ChatGPT

Am luat în considerare mai sus o interogare generală (prompt) către ChatGPT, de la care puteți începe să analizați un contract inteligent. Dar, desigur, analiza detaliată nu se limitează la promptul introductiv.

Scammerii își îmbunătățesc în mod constant tacticile, așa că trebuie să fiți informați și precauți în multe aspecte - acestea sunt strategii esențiale pentru a vă proteja investiția în token.

Să aruncăm o privire la o listă a primelor 100 de interogări care vă vor oferi o abordare profesională a auditului unui contract inteligent:

1. Codul se compilează cu succes?
2. Ce versiune de Solidity este utilizată în cod? Este aceasta versiunea stabilă curentă?
3. Sunt prezente comentarii clare care explică scopul funcțiilor și variabilelor?
4. Contractul utilizează o schemă "Ownable"? Dacă da, pentru ce funcții?
5. Variabilele de stare sunt alocate corect folosind modificatori de vizibilitate?
6. Evenimentele sunt utilizate pentru o logare adecvată?
7. Sunt furnizate mesaje de eroare ușor de utilizat?
8. Este verificată valoarea de retur a apelurilor de nivel scăzut?
9. Există scenarii în care proprietarul se poate autoriza care ar putea duce la tragerea covorului?
10. Cine deține controlul asupra conturilor privilegiate și care sunt mecanismele de control?
11. Ce mecanisme de guvernanță există în contract și guvernanța este complet deschisă sau limitată?
12. Sunt utilizate alte contracte în sistem și ce roluri îndeplinesc acestea (de exemplu, contractul proxy)?
13. Există un mecanism de blocare în timp și poate fi eludat?
14. Există o documentație adecvată disponibilă?
15. Există vulnerabilități potențiale la atacuri DoS sau de reentranță în cod?
16. Toate funcțiile sunt interne, cu excepția celor care trebuie în mod explicit să fie publice/externe?
17. Nu există depășiri/subdepășiri aritmetice în operațiunile matematice?
18. Se utilizează biblioteca sigură OpenZeppelin?
19. Etherul sau tokenurile nu pot fi trimise accidental la o adresă nulă (0x0)?
20. Condițiile sunt verificate cu require înainte de operații și schimbări de stare?
21. Se stabilește starea înainte și în timpul executării acțiunilor?
22. Se utilizează protecția împotriva atacurilor de reintroducere (reentry) (A apelează B apelează A)?
23. Interfața ERC20 este implementată în mod corespunzător?
24. Modificatorul este utilizat în mai multe locuri numai dacă este cu adevărat necesar?
25. Toate tipurile sunt stabilite în mod explicit (de exemplu, uint256 este utilizat în loc de uint)?
26. Toate metodele și ciclurile se încadrează în limita maximă admisibilă a gazelor?
27. Nu există inițializări inutile în constructor (amintiți-vă că valorile implicite sunt setate)?
28. Există o acoperire completă a testelor: fiecare metodă de contract inteligent și toate tipurile posibile de date de intrare sunt testate?
29. Au fost efectuate teste fuzz folosind intrări aleatorii?
30. Sunt testate toate stările posibile în care se poate afla un contract?
31. Cantitățile implicite de ether și jetoane sunt specificate în unități de wei?
32. Blocul/timpul de încheiere a crowdsale vine după blocul/timpul de începere (începerea/activarea tranzacționării)?
33. Taxa de schimb/conversie a jetoanelor crowdsale este setată corect?
34. Există o limită soft/hard de crowdsale setată?
35. Este stabilită și testată contribuția minimă/maximă permisă la crowdsale?
36. A fost testată funcționalitatea de whitelisting la crowdsale?
37. A fost verificată logica de rambursare la crowdsale?
38. Participanții la crowdsale primesc un număr proporțional de jetoane sau își pot revendica contribuția?
39. Durata fiecărei etape a crowdsale (de ex, pre-vânzare, vânzare publică) configurată corespunzător?
40. Se specifică ce funcții ar trebui să fie controlate numai de către proprietar (de ex, punerea în pauză a crowdsale-ului, trecerea la o altă etapă a crowdsale-ului, activarea distribuției de jetoane etc.)?
41. Este verificată logica de vesting (investire) a crowdsale-ului?
42. Crowdsale are un mod de siguranță care, atunci când este activat de către proprietar, limitează apelurile funcției și include o funcție de rambursare?
43. Crowdsale are o caracteristică de rezervă dacă are un sens rezonabil.
44. Bibliotecile importate au fost verificate în prealabil și nu conțin părți nedorite care ar putea fi înlocuite în versiunile viitoare și ar putea fi utilizate în scopuri rău intenționate?
45. Metodele de transfer de jetoane (transfer) învelite în require?
46. Sunt utilizate corect require și assert? Metoda assert este utilizată numai pentru lucruri care nu ar trebui să se întâmple niciodată, de obicei este utilizată pentru a verifica starea după ce au fost efectuate modificări.
47. Există o apărare împotriva atacurilor de apelare recursivă?
48. Sunt limitate lungimile șirurilor arbitrare din intrare?
49. Unde este posibil, evitați utilizarea array-urilor și utilizați în schimb mapări?
50. Nu sunt utilizate hașuri de bloc pentru a gestiona valori aleatorii (minerii pot afecta acest lucru)?
51. Nu utilizează tx.origin nicăieri?
52. Elementele array sunt deplasate în jos atunci când un element este șters pentru a nu lăsa goluri?
53. Se utilizează revert în loc de throw?
54. Funcțiile se termină imediat dacă condițiile nu sunt îndeplinite?
55. Au fost rezolvate avertismentele compilatorului?
56. Se utilizează biblioteca SafeMath în calcule?
57. Se citesc mai multe sloturi de memorie (sloturi de stocare) de mai multe ori?
58. Se utilizează bucle/șiruri nemărginite care ar putea cauza DoS?
59. Se utilizează block.timestamp numai pentru intervale lungi?
60. Nu se utilizează block. number pentru a calcula timpul scurs?
61. Se evită apelul delegatecall, în special pentru contractele externe (chiar dacă sunt de încredere)?
62. Nu se actualizează lungimea array-ului în timpul iterației peste acesta?
63. Sunt semnăturile protejate împotriva redării cu nonce și block.chainid?
64. Asigurați-vă că toate semnăturile utilizează EIP-712?
65. Sosirea lui abi.encodePacked() nu ar trebui să fie hașurată dacă sunt utilizate mai mult de 2 tipuri dinamice. În general, este preferabil să se utilizeze abi.encode().
66. Verificați cu atenție inserțiile de cod de asamblare.
67. Evitați consumul insuficient de gaz (gas griefing).
68. Sunt toate datele private cu adevărat private?
69. Actualizarea unei structuri/unui array în memorie (memorie) nu îl va modifica în stocare (etapă)?
70. Variabilele de etapă sunt eclipsate?
71. Calcularea valorii unei variabile din mers este mai ieftină decât stocarea acesteia?
72. Toate variabilele de stare sunt citite din contractul corect (master vs. clonă)?
73. Operatorii de comparație (>, <, >=, <=) sunt utilizați corect, în special pentru a preveni erorile off-by-one?
74. Operatorii logici (==, ! =, &&, ||, !) sunt utilizați corect, în special pentru a preveni erorile off-by-one?
75. Întotdeauna se efectuează înmulțirea înainte de împărțire (cu excepția cazului în care înmulțirea poate depăși limita)?
76. Numerele magice sunt înlocuite cu o constantă cu un nume intuitiv?
77. Dacă un destinatar ETH are o funcție de rezervă (fallback ) care poate fi inversată, aceasta ar putea duce la un DoS?
78. Se utilizează standardul SafeERC20 și valorile de retur sunt verificate într-un mod sigur?
79. Se presupune că msg. este întotdeauna un utilizator relevant?
80. Nu se utilizeazăx.origin pentru autorizare?
81. Nu se utilizează address.transfer() sau address.send() în loc de .call.value()?
82. Când utilizați apeluri de nivel scăzut, asigurați-vă că există un contract înainte de apel.
83. Se utilizează codul de asamblare pentru accesarea codului chainid sau a codului contractului/dimensiunii/hash în loc de sintaxa Solidity?
84. Se utilizează cuvântul cheie delete atunci când se setează o variabilă la o valoare nulă (0, false, "" etc.)?
85. Expresiile trecute la operatorii/comparările logice (&&/||/>=/==/etc) nu trebuie să aibă efecte secundare.
86. Când aveți de-a face cu adrese multiple, întrebați-vă ce se întâmplă dacă acestea sunt aceleași?
87. Cât de bine documentat este codul? Sunt furnizate comentarii și exemple ori de câte ori se utilizează cod non-standard?
88. Dacă se utilizează apelul extern, asigurați-vă că un apel extern de contract este cu adevărat necesar?
89. Se verifică rezultatul apelului extern și sunt gestionate erorile?
90. Ce se întâmplă dacă apelul extern utilizează tot gazul furnizat?
91. Dacă apelul extern apelează o funcție specifică, asigurați-vă că funcția există cu adevărat (funcții fantomă).
92. Asigurați-vă că nu sunt utilizate apeluri externe în modificatori (modificatori)
93. Sunt emise evenimente pentru fiecare funcție care modifică stocarea?
94. Verificați-vă ipotezele cu privire la ceea ce fac și returnează contractele externe utilizate în principal.
95. Aveți grijă la jetoanele care utilizează prea multe sau prea puține zecimale. Asigurați-vă că valorile maxime și minime acceptate sunt documentate.
96. Autoritatea asociată rolurilor este documentată?
97. Care sunt riscurile atunci când drepturile de acces sunt încălcate și cum poate afecta acest lucru diversele componente ale sistemului?
98. Puterea proprietarului de a manipula jetoanele și ETH în cadrul contractului?
99. Cum este stabilită adresa oracolului (Oracle) și care este procesul din spatele acesteia? Există oracole de rezervă pentru backup?
100. Cum sunt implementate funcții similare în alte proiecte, au fost luate în considerare cele mai bune practici?

Această listă de verificare vă va ajuta să vă asigurați că efectuați un audit de securitate complet al contractelor inteligente Solidity. Ea acoperă o gamă largă de aspecte critice pentru a identifica și a atenua potențialele vulnerabilități și riscuri din cod și din sistemele aferente.

 

Sperăm că aceste exemple v-au ajutat să înțelegeți mai bine metodologia de audit a contractelor inteligente.

 

De vreme ce toate informațiile din blockchain sunt deschise (cu condiția, desigur, ca codul sursă al contractului să fie verificat), înarmat cu aceste cunoștințe, puteți studia independent contractele inteligente și identifica diverse scheme de înșelăciune.

De altfel, noi am făcut deja totul pentru dumneavoastră! Înscrieți-vă pentru un abonament premium și obțineți acces la filtre exclusive privind caracteristicile contractelor inteligente și la analize proaspete. Creșteți-vă șansele de a investi cu succes în token-uri profitabile.

Regards, Lotus Market team.

All posts