Contratti intelligenti autoverificati con ChatGPT

Quando si procede all'audit degli smart contract, è necessario affrontare un'ampia gamma di questioni per garantire la sicurezza del codice. Queste domande riguardano vari aspetti, tra cui il controllo degli accessi, la gestione delle risorse, la gestione dei dati, le assunzioni, le dipendenze e le liste di controllo della sicurezza. Di seguito forniamo una lista di controllo dettagliata e le istruzioni per le query di ChatGPT per guidarvi attraverso il processo di verifica degli smart contract.

Se volete indagare voi stessi su uno smart contract alla ricerca di vulnerabilità e tecniche di truffa nascoste, il primo passo è una richiesta di ChatGPT correttamente realizzata.

Una query utile per ChatGPT potrebbe essere il seguente comando:

Fornite un elenco completo di tutti i problemi e le vulnerabilità nel seguente smart contract. Descrivete i problemi e le possibili vulnerabilità in dettaglio. Fornire uno scenario di sfruttamento per ogni vulnerabilità. Fornire una tabella valida in formato markdown con un elenco di oggetti, ciascuno con le colonne "descrizione", "azione", "gravità", "attori", "scenario", "tipo" e "riga". 'tipo' dove può essere 'usabilità', 'vulnerabilità', 'ottimizzazione' o 'suggerimento'. 'attori' è un elenco di attori coinvolti. severità" può essere "bassa", "media" o "alta". 'riga' è il numero di riga del problema. Assicuratevi che tutti i campi della tabella siano compilati.

Usate quindi le seguenti domande per esplorare lo smart contract in modo più approfondito.

Scenari di utilizzo:

1. Chi sono gli attori del sistema?


2. Quali azioni ha il sistema?


3. Quali sono le limitazioni del sistema?


4. Quali sono i potenziali modi per violare il sistema?


5. Quali difese vengono utilizzate per contrastare gli attacchi?


6. Descrivere, sulla base dei vincoli, i cambiamenti di stato di ciascuna funzione.


7. Fornire informazioni sui modelli Solidity e DeFi utilizzati.


8. Scrivere assiomi positivi e negativi in base alle informazioni sul sistema.


9. Elencare i modi per ottimizzare e modificare il codice per renderlo più affidabile (con frammenti di codice).


10. Elencare i metodi di truffa nascosti utilizzati nel codice (con frammenti di codice).

Suggerimento: La rappresentazione visiva dei dati spesso fornisce una comprensione più chiara del funzionamento del sistema. Quando si lavora con ChatGPT, si raccomanda di richiedere la visualizzazione dei dati di output, come le modifiche di stato sotto forma di diagrammi di caratteri ASCII. Anche se non tutte le visualizzazioni possono avere senso, alcune possono fornire indicazioni molto preziose sul funzionamento di uno smart contract.

Infatti, sebbene ChatGPT non possa sostituire un revisore umano, integra in modo significativo il processo di auditing fornendo una comprensione più chiara delle transizioni di stato del protocollo, dei vincoli, degli invarianti e della compatibilità. Questo strumento è particolarmente efficace per la comprensione delle transizioni di stato e dei vincoli del protocollo.

Suggerimento: Prima di iniziare un audit, fornire al chatbot la documentazione sul protocollo oggetto dell'audit può migliorare notevolmente l'accuratezza e la pertinenza delle risposte. Basta dire: "Questa è la documentazione che fornisce il miglior contesto per il 'nome_protocollo' che sto verificando" e inserire il documento.

Si può dire che ChatGPT è un potente assistente per gli auditor, che fornisce un approccio strutturato e approfondito alla verifica degli smart contract. Tuttavia, va tenuto presente che ChatGTP (e servizi simili) sono solo interpretazioni complesse dell'analisi meccanica che lavora con le probabilità, quindi spesso producono errori e imprecisioni. Di conseguenza, non ci si può fidare completamente del risultato di ChatGPT: è solo un buon strumento nelle mani giuste e un "punto di partenza" nella ricerca sui contratti intelligenti.

Pertanto, per proteggersi da eventuali rischi, i contratti smart dovrebbero essere esaminati più attentamente per individuare eventuali vulnerabilità e schemi fraudolenti.

Come eseguire una verifica approfondita dei contratti smart? Le 100 richieste più frequenti a ChatGPT

Qui sopra abbiamo considerato una richiesta generale (prompt) a ChatGPT, da cui si può partire per analizzare uno smart contract. Ma, naturalmente, l'analisi dettagliata non si limita alla richiesta introduttiva.

I truffatori migliorano costantemente le loro tattiche, quindi è necessario essere informati e cauti sotto molti aspetti - queste sono strategie essenziali per proteggere il vostro investimento in token.

Diamo un'occhiata a un elenco delle 100 principali richieste che vi forniranno un approccio professionale alla verifica di uno smart contract:

1. Il codice viene compilato con successo?
2. Quale versione di Solidity viene utilizzata nel codice? È l'attuale versione stabile?
3. Sono presenti commenti chiari che spiegano lo scopo delle funzioni e delle variabili?
4. Il contratto utilizza uno schema "Ownable"? Se sì, per quali funzioni?
5. Le variabili di stato sono allocate correttamente utilizzando i modificatori di visibilità?
6. Gli eventi sono utilizzati per un corretto logging?
7. Sono forniti messaggi di errore user-friendly?
8. Il valore di ritorno delle chiamate di basso livello è controllato?
9. Ci sono scenari in cui il proprietario può autorizzare se stesso che potrebbero portare al rug-pulling?
10. Chi ha il controllo sugli account privilegiati e quali sono i meccanismi di controllo?
11. Quali meccanismi di governance esistono nel contratto e la governance è completamente aperta o limitata?
12. Vengono utilizzati altri contratti nel sistema e quali ruoli svolgono (ad esempio, il contratto proxy)?
13. E' presente un meccanismo di blocco temporale e può essere aggirato?
14. È disponibile una documentazione adeguata?
15. Ci sono potenziali vulnerabilità per attacchi DoS o di rientranza nel codice?
16. Tutte le funzioni sono interne, tranne quelle che sono esplicitamente richieste come pubbliche/esterne?
17. Non ci sono overflow/underflow aritmetici nelle operazioni matematiche?
18. Si utilizza la libreria sicura OpenZeppelin?
19. Ether o token non possono essere inviati accidentalmente a un indirizzo nullo (0x0)?
20. Le condizioni sono verificate con require prima delle operazioni e dei cambiamenti di stato?
21. Lo stato è impostato prima e durante l'esecuzione delle azioni?
22. È utilizzata la protezione contro gli attacchi di rientro (A chiama B chiama A)?
23. L'interfaccia ERC20 è implementata correttamente?
24. Il modificatore è utilizzato in più punti solo se è veramente necessario?
25. Tutti i tipi sono impostati in modo esplicito (ad esempio, uint256 è utilizzato al posto di uint)?
26. Tutti i metodi e i cicli rientrano nel limite massimo di gas consentito?
27. Non ci sono inizializzazioni non necessarie nel costruttore (ricordarsi che i valori predefiniti sono impostati)?
28. C'è una copertura di test completa: ogni metodo di smart contract e tutti i possibili tipi di dati di input sono testati?
29. Il fuzz testing è stato eseguito utilizzando input casuali?
30. Sono stati testati tutti i possibili stati in cui può trovarsi un contratto?
31. Le quantità predefinite di ether e token sono specificate in unità di wei?
32. Il blocco/ora di fine crowdsale viene dopo il blocco/ora di inizio (avvio/abilitazione del trading)?
33. Il tasso di scambio/conversione dei token crowdsale è impostato correttamente?
34. E' impostato un limite soft/hard di crowdsale?
35. Il contributo minimo/massimo consentito alla crowdsale è stato impostato e testato?
36. La funzionalità di whitelist della crowdsale è stata testata?
37. La logica di rimborso della crowdsale è stata verificata?
38. I partecipanti alla crowdsale ricevono un numero proporzionale di token o possono reclamare il loro contributo?
39. La durata di ogni fase della crowdsale (ad es, prevendita, vendita pubblica) è configurata correttamente?
40. Si specifica quali funzioni devono essere controllate solo dal proprietario (ad es, sospendere la crowdsale, passare a un'altra fase della crowdsale, attivare la distribuzione dei token, ecc.)?
41. La logica di partecipazione alla crowdsale (vesting) è stata verificata?
42. La crowdsale ha una modalità fail-safe che, se attivata dal proprietario, limita le chiamate alla funzione e include una funzione di rimborso?
43. Crowdsale ha una funzione di fallback se ha un senso ragionevole.
44. Le librerie importate sono state controllate in anticipo e non contengono parti indesiderate che potrebbero essere sostituite in versioni future e utilizzate per scopi dannosi?
45. Metodi di trasferimento dei token (transfer) avvolti in require?
46. I metodi require e assert sono utilizzati correttamente? Il metodo assert è usato solo per cose che non dovrebbero mai accadere, di solito è usato per controllare lo stato dopo che sono state fatte delle modifiche.
47. C'è una difesa contro gli attacchi di chiamate ricorsive?
48. Le lunghezze delle stringhe arbitrarie nell'input sono limitate?
49. Ove possibile, si evita di usare gli array e si usano invece le mappature?
50. Non vengono utilizzati hash a blocchi per gestire valori casuali (i minatori possono influire su questo aspetto)?
51. Non viene utilizzato tx.origin da nessuna parte?
52. Gli elementi degli array vengono spostati verso il basso quando un elemento viene cancellato, in modo da non lasciare spazi vuoti?
53. Viene utilizzato revert al posto di throw?
54. Le funzioni terminano immediatamente se le condizioni non sono soddisfatte?
55. Gli avvisi del compilatore sono stati risolti?
56. La libreria SafeMath è usata nei calcoli?
57. Qualsiasi slot di memoria (slot di memorizzazione) è letto più di una volta?
58. Sono usati cicli/array non vincolati che potrebbero causare DoS?
59. Blocco.timestamp è usato solo per intervalli lunghi?
60. Non si usa blocco. number per calcolare il tempo trascorso?
61. La chiamata delegatecall viene evitata, specialmente per i contratti esterni (anche se affidabili)?
62. La lunghezza dell'array non viene aggiornata durante l'iterazione su di esso?
63. Le firme sono protette da replay con nonce e block.chainid?
64. Assicurarsi che tutte le firme utilizzino l'EIP-712?
65. L'output di abi.encodePacked() non dovrebbe essere sottoposto a hash se vengono utilizzati più di 2 tipi dinamici. In generale è preferibile usare abi.encode().
66. Controllare attentamente gli inserimenti di codice assembly.
67. Evitare un consumo insufficiente di gas (gas griefing).
68. Tutti i dati privati sono veramente privati?
69. L'aggiornamento di una struttura/array in memoria (memory) non la modificherà in memoria (stage)?
70. Le variabili di stage sono overshadowed?
71. Calcolare il valore di una variabile al volo è più economico che memorizzarlo?
72. Tutte le variabili di stato sono lette dal contratto corretto (master vs. clone)?
73. Gli operatori di confronto (>, <, >=, <=) sono usati correttamente, soprattutto per evitare errori off-by-one?
74. Gli operatori logici (==, ! =, &&, ||, !) sono usati correttamente, soprattutto per evitare errori di tipo off-by-one?
75. La moltiplicazione viene sempre eseguita prima della divisione (a meno che la moltiplicazione non possa traboccare)?
76. I numeri magici sono sostituiti da una costante con un nome intuitivo?
77. Se un destinatario ETH ha una funzione di ripiego (fallback ) che può essere annullata, questo potrebbe portare a un DoS?
78. Lo standard SafeERC20 è utilizzato e i valori di ritorno sono controllati in modo sicuro?
79. Si presume che il mittente del msg. sia sempre un utente rilevante?
80. Non si usa tx.origin per l'autorizzazione?
81. Non si usa address.transfer() o address.send() invece di .call.value()?
82. Quando si usano chiamate di basso livello, assicurarsi che esista un contratto prima della chiamata.
83. Si usa il codice assembly per accedere al chainid o al codice contratto/dimensione/hash invece della sintassi di Solidity?
84. Si usa la parola chiave delete quando si imposta una variabile a un valore nullo (0, false, "", etc.)?
85. Le espressioni passate agli operatori logici/confronti (&&/||/>=/==/etc) non devono avere effetti collaterali.
86. Quando si ha a che fare con indirizzi multipli, chiedersi cosa succede se sono uguali?
87. Quanto è ben documentato il codice? Vengono forniti commenti ed esempi laddove si utilizza codice non standard?
88. Se si utilizza una chiamata esterna, ci si assicura che la chiamata a un contratto esterno sia davvero necessaria?
89. Il risultato della chiamata esterna viene controllato e vengono gestiti gli errori?
90. Cosa succede se la chiamata esterna utilizza tutto il gas fornito?
91. Se la chiamata esterna chiama una funzione specifica, ci si assicura che la funzione esista davvero (funzioni fantasma).
92. Assicurarsi che non vengano usate chiamate esterne nei modificatori (modificatori)
93. Gli eventi vengono emessi per ogni funzione che modifica lo storage?
94. Controllare le ipotesi su cosa fanno e restituiscono i contratti esterni usati nel main.
95. Assicurarsi dei token che usano troppi o troppo pochi decimali. Assicuratevi che i valori massimi e minimi supportati siano documentati.
96. L'autorità associata ai ruoli è documentata?
97. Quali sono i rischi quando i diritti di accesso vengono violati e come ciò può influire sui vari componenti del sistema?
98. Il proprietario può manipolare i token e gli ETH all'interno del contratto?
99. Come viene impostato l'indirizzo dell'oracolo (Oracle) e qual è il processo alla base? Esistono oracoli di riserva per il backup?
100. Come vengono implementate funzioni simili in altri progetti, sono state prese in considerazione le migliori pratiche?

Questa lista di controllo vi aiuterà a garantire un audit di sicurezza approfondito degli smart contract Solidity. Copre un'ampia gamma di aspetti critici per identificare e mitigare potenziali vulnerabilità e rischi nel codice e nei sistemi correlati.

 

Speriamo che questi esempi vi abbiano aiutato a comprendere meglio la metodologia di audit degli smart contract.

 

Dal momento che tutte le informazioni nella blockchain sono aperte (a condizione, ovviamente, che il codice sorgente del contratto sia verificato), armati di questa conoscenza potete studiare in modo indipendente gli smart contract e identificare vari schemi di truffa.

Tuttavia, abbiamo già fatto tutto per voi! Sottoscrivete un abbonamento premium e avrete accesso a filtri esclusivi sulle caratteristiche dei contratti intelligenti e a nuove analisi. Aumenta le tue possibilità di investire con successo in token redditizi.

Regards, Lotus Market team.

All posts