Come le applicazioni Ethereum ottengono valutazioni di sicurezza A+

Oltre 1,2 milioni di applicazioni Ethereum hanno utilizzato uno strumento di sicurezza poco conosciuto per aiutarle a evitare costosi errori derivanti da linee di codice autoeseguibili note come contratti intelligenti.

Lanciato dalla startup Tecnologie Ethereum Amberdata a ottobre, lo strumento gratuito è disponibile per chiunque nel pubblico generale per interpretare la sicurezza delle applicazioni attive sulla blockchain Ethereum . Gli smart contract con bug che sono stati sfruttati hanno portato a enormi perdite, anche dell'ordine dicentinaia di milioni.

Il servizio automatizzato esegue la scansione delle vulnerabilità comuni trovate nel codice dello smart contract e genera una valutazione in lettere (ad esempio A, B o C) per la sicurezza di un'applicazione decentralizzata (dapp).

Questa funzionalità è ONE dei tanti strumenti che incoraggiano le buone pratiche e una maggiore trasparenza tra gli sviluppatori di dapp e gli utenti finali nell'ecosistema Ethereum .

Inoltre, è una funzionalità che è presente nel più ampio spazio web da parecchio tempo. Il browser attento alla privacy DuckDuckGo ha recentemente lanciato un'estensione del browser Chrome utilizzata per classificare i siti web (non le dapp) con un voto in lettere, offrendo agli utenti una facile panoramica di quanto bene o male gli amministratori dei servizi proteggano la Privacy degli utenti.

"La nostra visione è quella di elevare lo standard di fiducia online", scrive DuckDuckGo in unpost del blogda gennaio 2017.

Analogamente, la visione alla base dello strumento di valutazione della sicurezza di Amberdata, come sottolineato dal CEO di Amberdata Shawn Douglass in un comunicato stampa, è quella di fornire "un maggiore accesso e una migliore visibilità sui contratti intelligenti".

Ha aggiunto:

"Ci auguriamo che fornendo questi strumenti alla comunità potremo ridurre le dipendenze esterne e consentire alla comunità di svilupparsi in modo più rapido e sicuro".

Le valutazioni

Ma come vengono valutate esattamente queste applicazioni su Ethereum su Amberdata?

Indicando 13 tipi di vulnerabilità analizzate automaticamente dal programma, il CTO di Amberdata Joanes Espanol ha paragonato ciascuna di queste alle “spie del motore sul cruscotto [di un’auto]”.

"Significa solo che devo controllare cosa sta succedendo con l'auto. Ognuna di queste cose può causare un errore di sicurezza", ha spiegato Espanol a CoinDesk.

E più errori di sicurezza vengono rilevati dalla scansione di sicurezza di Amberdata, più basso sarà il punteggio in lettere dell'alfabeto che riceverà una dapp. Queste valutazioni vanno da A+ fino a F.

Ma T dipendono strettamente dal numero di errori di sicurezza. Ognuna delle 13 vulnerabilità ha diversi gradi di gravità, spiega Espanol, che avranno un impatto sul voto finale di una dapp. Due comuni vulnerabilità di bassa gravità segnalate da Espanol includono "chiamata delegata a un indirizzo fornito dall'utente" e "chiamata messaggio a contratto esterno".

Quest'ultimo può rappresentare un potenziale rischio per la sicurezza se una dapp, anziché essere autosufficiente in ONE smart contract, richiama contratti aggiuntivi contenenti codice buggato.

Allo stesso modo, una chiamata delegata è un'altra operazione normalmente utilizzata per suddividere il codice di uno smart contract in più sottocontratti, in modo che eventuali aggiornamenti necessari al software possano essere effettuati in modo frammentario senza terminare l'intera applicazione.

"Quella è la parte buona di quelle chiamate dei delegati. Ma la parte cattiva è che ora, come proprietario del contratto, potrei iniziare a fare cose cattive. Quindi, potrei iniziare a sostituire i contratti che modificano il comportamento dell'[applicazione] originale", ha spiegato Espanol.

Pertanto, su entrambi i fronti, Espanol ha descritto l’audit di sicurezza come l’invio di “avvisi”, piuttosto che l’indicazione di errori immediati nel codice.

In effetti, ONE di queste dapp che attualmente sfrutta la chiamata dei messaggi e che in precedenza aveva distribuito un aggiornamento del contratto intelligente tramite chiamata delegata a gennaio è TrueUSD. Creata dalla startup blockchain TrustToken, la stablecoin supportata da USD su Ethereum è attualmente classificata con un Voto: C.

Sebbene ciò T suoni bene, esaminando le vulnerabilità segnalate per TrueUSD, l'ingegnere della sicurezza di TrustToken William Morriss ha dichiarato a CoinDesk in una precedente intervista che in realtà non tutte le preoccupazioni identificate erano "critiche".

"Le vulnerabilità che vengono segnalate non sono modi in cui possiamo essere attaccati... Ne siamo consapevoli e quando le persone ci segnalano vulnerabilità le trattiamo molto seriamente", ha affermato Morriss.

Approfondendo specificamente la questione delle chiamate tramite messaggio, Morriss ha aggiunto che, per TrueUSD, tutti i contratti esterni sono di proprietà e gestiti dalle aziende stesse, a differenza di terze parti con standard di sicurezza potenzialmente inferiori.

Come ottenere un A+

Gli errori di gravità "elevata" incideranno maggiormente sulla valutazione di sicurezza dell'applicazione, perché indicano un potenziale maggiore di errori e exploit del codice.

ONE dei più comuni, "integer overflow", indica che le operazioni eseguite all'interno di uno smart contract potrebbero generare valori che superano i limiti del codice, portando a comportamenti stravaganti e imprevedibili che, nel peggiore dei casi, potrebbero portare alla perdita di fondi.

Il rovescio della medaglia è l'“integer underflow”, un'altra vulnerabilità di gravità “elevata”, per cui potrebbe verificarsi l'esatto opposto e un valore al di sotto dell'intervallo definito causa analogamente un output errato.

Ci sono anche alcune funzionalità in Solidity che gli sviluppatori di dapp dovrebbero semplicemente evitare, secondo il sistema di valutazione di Amberdata, tra cui "suicide()" e "tx.origin". Quest'ultimo è descritto da Espanol come "codice deprecato" che potrebbe essere rimosso completamente dal linguaggio Solidity in futuro, mentre il primo rischia di essere dirottato da terze parti per congelare i fondi degli utenti, che non potranno mai più recuperare.

Poiché T presenta nessuna di queste quattro vulnerabilità, infamemente la popolare app di Ethereum CryptoKitties ha attualmente un Un +valutazione di sicurezza su Amberdata. L'ingegnere informatico di CryptoKitties Fabiano Soriani attribuisce questo al fatto di "implementare quanti più test possibile".

Aggiungendo che le “risorse passive” come la documentazione scritta e i tutorial video sullo sviluppo di dapp non sono sufficienti per creare applicazioni sicure su Ethereum, Soriani ha detto a CoinDesk:

"Quando qualcuno esegue un audit, Per te fa notare le cose. È un'ottima risorsa complementare [alle risorse passive] perché gli sviluppatori che provengono da un background più tradizionale T hanno familiarità con la blockchain".

"Si tratta di una nuova serie di problemi"

In effetti, quando si tratta di creare dapp, l'importanza di un codice ermetico e impenetrabile non può essere sottovalutata. Il ragionamento CORE per questo è duplice.

Innanzitutto, a differenza delle applicazioni tradizionali, le dapp sono generalmente programmi per computer open source e, come spiega Morriss, è richiesto "un livello di cautela elevato" quando si esegue codice "pubblico".

"Se c'è un bug in un'applicazione tradizionale, potresti farla franca per diversi anni... ma se hai un bug nel tuo contratto intelligente, le persone lo scopriranno piuttosto rapidamente e ne trarranno vantaggio, distruggendoti o traendone vantaggio", ha affermato Morriss.

In secondo luogo, le dapp su Ethereum funzionano esclusivamente su smart contract. Codificate appositamente nel linguaggio di programmazione Solidity ed eseguite nel centro nevralgico della blockchain chiamato Macchina virtuale Ethereum (EVM), uno dei punti di forza delle dapp è che T possono essere modificate.

Lo svantaggio di tutto questo è ovvio. I programmatori non sono facilmente in grado di correggere errori o bug nel software una volta distribuito sulla blockchain.

Definendolo un "grave errore" saltare un audit o una scansione di sicurezza di terze parti per questi motivi, Morriss ha detto a CoinDesk che era importante per gli sviluppatori non diventare vittime della propria "arroganza" e assicurarsi che "i test coprano ogni ramo del codice".

"Con Ethereum, si verifica una nuova serie di problemi di cui le persone T sono consapevoli quando programmano in Solidity", ha sottolineato Espanol a CoinDesk.

Immagine di programmazionetramite Shutterstock