Rapporto di verifica Snap Metamask per Sei

Sommario di gestione

Sei ha contattato Sayfer Security per eseguire test di penetrazione su MetaMask Snap di Sei nel gennaio 2024.

Prima di valutare i servizi di cui sopra, abbiamo tenuto un incontro iniziale con il team tecnico di Sei e abbiamo ricevuto una panoramica del sistema e degli obiettivi di questa ricerca.

Durante il periodo di ricerca di 2 settimane, abbiamo scoperto 3 vulnerabilità nel sistema.

In conclusione, a seguito del rapporto dovrebbero essere implementate diverse soluzioni, ma il livello di sicurezza del sistema è adeguato.

Dopo una revisione da parte del team Sayfer, certifichiamo che tutti i problemi di sicurezza menzionati in questo rapporto sono stati risolti dal team Sei.

Metodologia del rischio

Noi di Sayfer ci impegniamo a fornire ai nostri clienti test di penetrazione della massima qualità. Ecco perché abbiamo implementato un modello completo di valutazione del rischio per valutare la gravità dei nostri risultati e fornire ai nostri clienti le migliori raccomandazioni possibili per la mitigazione.

Il nostro modello di valutazione del rischio si basa su due fattori chiave: IMPATTO ed PROBABILITÀ. L'impatto si riferisce al danno potenziale che potrebbe derivare da un problema, come una perdita finanziaria, un danno alla reputazione o un sistema non operativo. La probabilità si riferisce alla probabilità che si verifichi un problema, tenendo conto di fattori quali la complessità dell'attacco e il numero di potenziali aggressori.

Combinando questi due fattori, possiamo creare una comprensione completa del rischio posto da un particolare problema e fornire ai nostri clienti una valutazione chiara e attuabile della gravità del problema. Questo approccio ci consente di dare priorità alle nostre raccomandazioni e garantire che i nostri clienti ricevano la migliore consulenza possibile su come proteggere la loro attività.

Il rischio è definito come segue:

Metodologia di valutazione della sicurezza

Sayfer utilizza OWASP WSTG come nostro standard tecnico durante la revisione delle applicazioni web. Dopo aver acquisito una conoscenza approfondita del sistema, abbiamo deciso quali test OWASP sono necessari per valutare il sistema.

Valutazione della sicurezza

Dopo aver compreso e definito l'ambito, eseguito la modellazione delle minacce e valutato i test corretti richiesti per verificare completamente l'eventuale presenza di difetti di sicurezza nell'applicazione, abbiamo eseguito la nostra valutazione della sicurezza.

Descrizione della tabella dei problemi

Titolo del problema

Descrizione

Qui forniamo una breve descrizione del problema e di come si è formato, i passaggi che abbiamo effettuato per individuarlo o sfruttarlo, insieme alla prova di concetto (se presente) e in che modo questo problema può influire sul prodotto o sui suoi utenti.

Mitigazione

Opzioni di risoluzione suggerite per questo problema e collegamenti a siti consigliati per ulteriori soluzioni.

Risultati della valutazione della sicurezza

[L] Le funzioni ritornano in caso di fallimento senza generare un errore

Descrizione

Quando si chiama il signDirect ed signAmino gestori, se account or account.privateKey non esistono, il programma termina senza restituire un messaggio di errore. Sebbene ciò non rappresenti una minaccia dal punto di vista della sicurezza, l'utente non riceverà alcun feedback utile che spieghi il motivo per cui lo snap non è riuscito.

• src/api.ts:30, 65

if (!account?.privateKey) return;

Mitigazione

Quando il programma fallisce, dovrebbe sempre restituire un messaggio di errore e mostrarlo all'utente.

[I] Funzione non utilizzata

Descrizione

I getWallet funzione in snapWallet.ts non viene chiamato da alcun gestore RPC definito nello snap. Inoltre nel pacchetto principale esiste già una funzione identica con lo stesso contenuto.

Mitigazione

L'esistenza di questo metodo duplicato non sembra svolgere alcuna funzionalità. Può essere rimosso in sicurezza.

[I] Documentazione mancante

Descrizione

Lo snap non sembra contenere alcuna forma di documentazione tecnica che spieghi i singoli metodi RPC, la loro applicazione o i requisiti funzionali che il codice dovrebbe soddisfare. È buona norma avere una descrizione di ciascun punto di ingresso reso disponibile agli utenti per l'uso.

Mitigazione

Suggeriamo di creare una documentazione tecnica che indichi la descrizione di ciascun gestore RPC, nonché di descrivere le modalità di comunicazione con essi a livello di dApp.