Vai al contenuto principale

Aiuta ad aggiornare questa pagina

ūüĆŹ

C'è una nuova versione di questa pagina, ma al momento è solo in inglese. Aiutaci a tradurre l'ultima versione.

Traduci la pagina
Visualizza in inglese

Nessun bug qui!ūüźõ

Questa pagina non è stata tradotta. Per il momento, è stata intenzionalmente lasciata in inglese.

Elenco di controllo per l'integrazione dei token

Solidity
Smart Contract
sicurezza
token
Intermedio
‚úćÔłŹTrailofbits
ūüďöCreare contratti sicuri
ūüďÜ13 agosto 2020
‚ŹĪÔłŹ5 minuti letti

Segui questo elenco di controllo quando interagisci con token arbitrari. Assicurati di conoscere i rischi associati a ogni oggetto e giustifica ogni eccezione a queste regole.

Per comodità, tutte le utilità di Slither sono direttamente eseguibili su un indirizzo di un token, come:

Uso del tutorial di Slither

slither-check-erc 0xdac17f958d2ee523a2206206994597c13d831ec7 TetherToken

Per seguire questo elenco di controllo, è utile questo output da Slither per il token:

- slither-check-erc [target] [contractName] [optional: --erc ERC_NUMBER]
- slither [target] --print human-summary
- slither [target] --print contract-summary
- slither-prop . --contract ContractName # requires configuration, and use of Echidna and Manticore

Considerazioni generali

  • Il contratto ha una revisione di sicurezza. Evita di interagire con i contratti che non hanno una revisione di sicurezza. Controlla la lunghezza della valutazione (cio√® il "livello di sforzo"), la reputazione dell'organizzazione di sicurezza e il numero e la gravit√† dei risultati.
  • Hai contattato gli sviluppatori. Potresti dover avvisare il loro team di un incidente. Cerca contatti appropriati su blockchain-security-contacts.
  • Hanno una mailing list di sicurezza per gli annunci critici. Il loro team dovrebbe avvisare gli utenti (come te!) quando vengono trovati problemi critici o quando viene eseguito un aggiornamento.

Conformità ERC

Slither include un'utilità, slither-check-erc, che revisiona la conformità di un token rispetto a molti standard ERC correlati. Usa slither-check-erc per controllare che siano soddisfatte le seguenti condizioni:

  • Transfer e transferFrom restituiscono un valore booleano. Diversi token non restituiscono un valore booleano per queste funzioni. Di conseguenza, le loro chiamate al contratto potrebbero non riuscire.
  • Il nome, i decimali e le funzioni del simbolo sono presenti se usati. Queste funzioni sono opzionali nello standard ERC20 e potrebbero non essere presenti.
  • I decimali restituiscono un uint8. Diversi token restituiscono erroneamente uint256. Se questo √® il caso, assicurati che il valore restituito sia inferiore a 255.
  • Il token mitiga la race condition di ERC20 nota. Lo standard ERC20 ha una race condition ERC20 che deve essere mitigata per impedire il furto di token da parte di aggressori.
  • Il token non √® un token ERC777 e non ha una chiamata di funzione esterna in transfer e transferFrom. Le chiamate esterne alle funzioni transfer possono determinare codice rientrante.

Slither include una utility, slither.prop che genera unit test e proprietà di sicurezza che possono scoprire molti difetti ERC comuni. Usa slither-prop per verificare quanto segue:

  • Il contratto supera tutti gli unit test e le propriet√† di sicurezza di slither-prop. Esegui gli unit test generati, poi controlla le propriet√† con Echidna e Manticore.

Infine, ci sono alcune caratteristiche che sono difficili da identificare automaticamente. Riesamina manualmente queste condizioni:

  • Transfer e transferFrom non devono richiedere commissioni. I token deflazionistici possono condurre a comportamenti imprevisti.
  • Vengono presi in considerazione gli interessi potenziali guadagnati dal token. Alcuni token distribuiscono interessi ai possessori di token. Questo interesse potrebbe rimanere intrappolato nel contratto se non preso in considerazione.

Composizione del contratto

  • Il contratto evita complessit√† inutili. Il token deve essere un contratto semplice; un token con codice complesso richiede uno standard superiore per il controllo. Usa la stampante human-summary di Slither per identificare il codice complesso.
  • Il contratto usa SafeMath. I contratti che non usano SafeMath richiedono uno standard di controllo superiore. Ispeziona manualmente il contratto per verificare l'uso di SafeMath.
  • Il contratto ha solo poche funzioni non correlate ai token. Le funzioni non correlate ai token aumentano la probabilit√† di un problema nel contratto. Usa la stampante contract-summary di Slither per controllare ampiamente il codice usato nel contratto.
  • Il token ha solo un indirizzo. I token con punti di ingresso multipli per gli aggiornamenti del saldo possono impedire il funzionamento della contabilit√† interna basata sull'indirizzo (es. balances[token_address][msg.sender] potrebbe non riflettere il saldo reale).

Privilegi del proprietario

  • Il token non √® aggiornabile. Le regole dei contratti aggiornabili potrebbero variare nel tempo. Usa la stampante human-summary di Slither per stabilire se il contratto √® aggiornabile.
  • Il proprietario ha capacit√† di conio limitate. I proprietari malevoli o compromessi possono abusare delle capacit√† di conio. Usa la stampante human-summary di Slither per verificare le capacit√† di conio e, se possibile, controlla manualmente il codice.
  • Il token non √® interrompibile. I proprietari malevoli o compromessi possono intrappolare i contratti che si basano su token interrompibili. Identifica il codice interrompibile manualmente.
  • Il proprietario non pu√≤ inserire il contratto nella lista nera. I proprietari malevoli o compromessi possono intrappolare i contratti che si basano su token con una lista nera. Identifica le funzionalit√† di blacklist a mano.
  • Il team legato al token √® noto e vi si pu√≤ attribuire la responsabilit√† di eventuali abusi. I contratti con team di sviluppo anonimi o che risiedono in rifugi legali devono richiedere uno standard di controllo superiore.

Scarsezza di token

Le verifiche dei problemi di scarsità dei token richiedono un controllo manuale. Verifica queste condizioni:

  • Nessun utente possiede la maggior parte della disponibilit√†. Se pochi utenti possiedono gran parte dei token, possono influenzare le operazioni in base alla ripartizione dei token.
  • La disponibilit√† totale di token √® sufficiente. I token con una limitata disponibilit√† totale sono facilmente manipolabili.
  • I token si trovano in pi√Ļ di un paio di scambi. Se tutti i token si trovano in un solo scambio, compromettere lo scambio pu√≤ causare la compromissione del contratto basato sul token.
  • Gli utenti comprendono i rischi associati a fondi di vaste dimensioni o prestiti lampo. I contratti che si basano sul saldo dei token devono fare molta attenzione agli aggressori con fondi molto estesi o attacchi tramite prestiti lampo.
  • I token non consentono il conio lampo. Il conio lampo pu√≤ condurre a oscillazioni sostanziali del saldo e della disponibilit√† totale, che necessitano di controlli rigorosi e completi dell'overflow nel funzionamento del token.
Ultima modifica: , Invalid DateTime
Modifica la pagina

Questa pagina è stata utile?