Perché un portafoglio può essere prosciugato “senza firma”
Obiettivo di questa guida: spiegare come funzionano i permessi
(l'approvazione è l'atto di concessione dei diritti, allowance è il limite di spesa registrato),
abbattere il principale
EVM è un gruppo di reti blockchain compatibili che utilizzano le stesse regole di esecuzione del contratto intelligente,
dove la gestione dei token e NFT è costruita attorno a un sistema di permessi.
In queste reti approve, allowance e
La principale vulnerabilità qui è l’aspettativa che ogni spesa richieda una firma separata. Nell'interfaccia di un portafoglio la firma appare come un passaggio ordinario ("consenti", "connetti", "conferma per lo scambio"), quindi l'utente conferma non un trasferimento, ma una concessione di diritti che viene memorizzato nel contratto e utilizzato successivamente senza un'altra finestra di conferma.
Un allowance non necessario
(un limite registrato nel contratto che definisce quanti token possono essere spesi)
per una stablecoin o un attivo
Se si valuta il rischio DeFi in modo più ampio rispetto alle approvazioni, aggiungi superfici di attacco separate alla tua lista di controllo: dApp frontend, bridge, MEV, chiavi ed errori operativi. DeFi guida alla sicurezza: mappa delle minacce ed elenco di controllo .
Il phishing di approvazione utilizza le concessioni di autorizzazioni tramite approve/permit
(creando o modificando un allowance)
o
Una firma approve/permit oppure
Cos’è il phishing di approvazione e perché la sua “onestà” è disonesta
Termini chiave in questa sezione:
-
Spendere è l'indirizzo dello smart-contract autorizzato a spendere i token ERC-20 del proprietario
all'interno di un allowance attraverso
transferFrom . -
Operatore è un indirizzo che ha ricevuto il diritto di trasferire il NFTs del proprietario
setApprovalForAll , senza limite al numero di token di raccolta. - Indennità è un valore in un contratto ERC-20 che definisce il numero massimo di token il spender può spendere.
- Revoke è una transazione che reimposta un allowance o disabilita un operator, porre fine al diritto di spendere o trasferire beni.
Il phishing di approvazione utilizza normali meccanismi di autorizzazione: la concessione dei diritti appare legittima, non comporta una perdita immediata di fondi e quindi spesso non viene percepita come un rischio al momento della firma.
Phishing di approvazione è un attacco in cui un utente viene convinto a concedere a permesso (approvazione/allowance) per gestire token o NFTs e tale diritto viene quindi utilizzato per prelevare risorse. L'azione pericolosa è mascherata da un passaggio dell'interfaccia familiare: "conferma per lo scambio", "consenti il conio", "firma per il reclamo", "concede l'accesso per il deposito".
A differenza del furto di chiavi, l’aggressore non ha bisogno della chiave privata e non ha bisogno di un trasferimento diretto di fondi. È sufficiente che l'utente lo faccia una volta concedere a un indirizzo specifico il diritto di spendere risorse: un spender per token ERC-20 o un operator per NFTs. Successivamente, il prelievo viene effettuato senza nuove finestre di portafoglio e senza ripetute conferme da parte del proprietario.
A livello blockchain, le transazioni sembrano valide: l’utente ha effettivamente cambiato lo stato del contratto e ha concesso i diritti su un indirizzo specifico. Ecco perché il portafoglio non viene formalmente “hackerato”: gli asset escono tramite permessi precedentemente concessi, non tramite bypass della firma.
Approve di solito non si trasferisce fondi immediatamente. Registra nel contratto del token un limite allowance, superato il quale il spender può chiamare
Sebbene l’equilibrio non sia cambiato, la firma è spesso percepita come sicura. Con approvazione illimitata o setApprovalForAll, un utente malintenzionato può ritirare le attività correnti e qualsiasi deposito futuro fino a quando lo stato allowance non viene reimpostato o lo stato operator viene disabilitato.
In termini semplici: approve non è un trasferimento, ma una concessione di diritti di spesa ad un indirizzo specifico. Phishing di approvazione significa che l'utente viene indotto con l'inganno a concedere tale diritto a un indirizzo controllato dall'aggressore mentre viene presentato come una normale fase di scambio, conio o rivendicazione.
Il phishing di approvazione funziona tramite autorizzazioni valide. Il pericolo si manifesta dopo la firma, quando viene utilizzato un diritto di spesa attivo senza la partecipazione del proprietario.
Le autorizzazioni in EVM sono registrazioni di diritti nei contratti, non azioni una tantum; ecco perché approve può rimanere attivo per mesi ed essere utilizzato senza firma ripetuta.
Come funzionano i permessi in EVM: allowance, spender e “infinito approve”
Un'autorizzazione EVM è un record di stato in un token o contratto NFT che collega il tuo indirizzo con un indirizzo spender/operator specifico. Questo record definisce chi può spendere i token
- ERC-20: approve → allowance → transferFrom
- L'utente chiama approve(spender, importo) e specifica l'indirizzo spender.
- Il contratto token memorizza il file allowance limite: il numero massimo di token che spender può spendere.
- Le chiamate spender transferFrom e spende i token senza nuove firme fino a quando il allowance diventa 0 o si esaurisce.
- Il contratto controlla allowance durante
transferFrom ; non richiede la firma del proprietario per ogni spesa.
- L'indennità è legata al proprietario → spender → token
- L'autorizzazione esiste solo per un token specifico e un spender specifico.
- Un approve per USDT non garantisce l'accesso a USDC e non si estende ad altri contratti.
- Ogni nuovo token o nuovo spender richiede un approve separato.
- L'approvazione illimitata è il valore massimo allowance
- Con approve illimitato, allowance memorizza il valore numerico massimo.
- Il spender riceve il diritto di spendere token da quel contratto entro questo valore, inclusi futuri depositi all'indirizzo.
- Il permesso rimane attivo fino ad una transazione revoke, anche se il servizio non viene più utilizzato.
- NFT: setApprovalForAll è lo stato operator senza limiti
- setApprovalForAll(operator, vero) abilita lo stato operator per l'intera collezione NFT del proprietario.
- Non si tratta di un limite di quantità o di valore: il diritto resta fino al setApprovalForAll(operator, falso) viene inviato.
- Se il operator è compromesso, NFTs può essere ritirato senza la conferma del nuovo proprietario.
Illimitato approve per ERC-20 aumenta l'importo massimo spendibile tramite
Le autorizzazioni EVM sono record di diritti di lunga durata nei contratti. Un approve può funzionare per mesi, aumenta in modo illimitato il limite di spesa disponibile e
Una firma permit (ad esempio EIP-2612) conferisce a un'applicazione il diritto di impostare allowance tramite un messaggio firmato; l'applicazione utilizza quindi quella firma in una transazione che concede i diritti ed esegue l'azione in una chiamata.
Autorizzazione, Permit2 e firme dei messaggi: come vengono concesse le autorizzazioni senza un approve separato e perché gli aggressori lo utilizzano
Oltre al normale approve, EVM dispone di modalità per concedere l'autorizzazione senza una transazione separata. L'utente semplicemente firma un messaggioe l'applicazione utilizza tale firma nella propria transazione, che garantisce il diritto di spesa ed esegue l'azione: scambio, deposito o richiesta. Questi meccanici sono chiamati permit ed estensioni come Permit2.
Da un punto di vista UX, sembrano essere necessari meno passaggi: non esiste una transazione approve separata e non è richiesto gas per una chiamata approve separata. La conseguenza tecnica è la stessa: nel contratto compare un diritto di spesa, e tale diritto può rimanere attivo al di là di una singola operazione se i parametri di firma fissano un limite ampio o una scadenza lunga.
I due tipi di conferma che gli utenti confondono più spesso:
- Transazione (sulla catena): approve / revoke / trasferimento: inviato alla rete, richiede gas e cambia lo stato del contratto.
- Firma del messaggio (fuori catena): permit e meccanismi simili: non è necessario gas al momento della firma, ma consentono a un'applicazione di installare gli stessi diritti di accesso.
| ⚙️ Meccanismo | 🧾 Quello che concedi | 📍 Dove appare | ⚠️ Rischio chiave |
|---|---|---|---|
| Approve (ERC-20) | Limite di spesa dei token per un spender | DEX, prestiti, agricoltura, ponti | Il allowance illimitato rimane attivo fino al revoke |
| Autorizzazione (EIP-2612 e analoghi) | Autorizzazione tramite una firma senza un approve separato | Scambi, aggregatori, interfacce DeFi “con un clic”. | La firma sembra “sicura” ma stabilisce diritti reali |
| Imposta approvazione per tutti (NFT) | Accesso globale all'intera collezione | Mercati, zecche, giochi dApps | NFTs può essere trasferito senza ripetute conferme |
Sfumatura chiave: approve e permit portano allo stesso risultato: un indirizzo specifico riceve il diritto di gestire il patrimonio del proprietario. Il modulo di conferma è diverso: una transazione on-chain o una firma del messaggio che viene successivamente utilizzata all'interno di una transazione.
Checklist pre-firma (30 secondi): un filtro rapido per vedere se una firma concede diritti di spesa.
- Cosa viene confermato? Permesso o approve indica una concessione di accesso.
- Chi riceve l'accesso? Guarda spender o operator nei parametri, non il design del sito.
- Qual è il limite? Illimitato sui token liquidi aumenta l'importo di spesa disponibile.
- C'è setApprovalForAll? Per NFTs questo è lo stato operator completo sulla raccolta.
- C'è urgenza? La pressione del tempo viene spesso utilizzata per indurre le persone a firmare senza controllare i parametri.
I permessi e le “firme gasless” cambiano solo la forma della conferma. Una firma del messaggio può installare diritti di accesso a token o NFTs proprio come approve, quindi i parametri della firma devono essere letti come concessioni di autorizzazioni.
Nei tipici schemi di phishing di approvazione, l'utente è portato a firmare approve/permit o
Tipici schemi di phishing di approvazione: come arrivare alla firma "giusta".
Questi schemi utilizzano interfacce familiari e flussi di lavoro standard, il che fa sembrare la concessione delle autorizzazioni una normale fase di servizio.
Quasi tutti gli attacchi seguono la stessa logica: prima l'utente viene portato su una pagina che assomiglia a un'interfaccia dApp, poi la pagina richiede una firma che concede un diritto di spesa o un diritto operator, e successivamente viene utilizzata l'autorizzazione attiva per prelevare beni senza nuove conferme.
La caratteristica fondamentale è l'assenza di una richiesta diretta di invio di un bonifico. Invece di un trasferimento, il sito richiede approve/permit oppure
- Clone di un servizio popolare
- Un dominio falso o un collegamento pubblicitario porta a una copia visivamente simile di un DEX o di un marketplace.
- L'interfaccia richiede approve “per scambio” o
setApprovalForAll "per l'elenco NFT". - I parametri della firma contengono un spender/operator che non appartiene al servizio reale.
- Compromissione dei canali ufficiali
- Un collegamento viene pubblicato in Discord, Telegram o X per conto del progetto o di un moderatore.
- Vengono utilizzati trigger di urgenza: “bug contrattuale”, “migrazione della menta”, “ultima possibilità”.
- Il collegamento porta a una pagina che richiede approve/permit per l'indirizzo dell'aggressore.
- Ingegneria sociale attraverso il “supporto”
- L'aggressore invia un messaggio privato fingendo di essere supporto del servizio.
- Viene richiesta una firma con il pretesto di “annullare una transazione bloccata”.
- In pratica l'utente firma un permit oppure concede un approve ad un indirizzo di terze parti.
- Sostituzione del significato della firma
- La finestra del portafoglio mostra una chiamata tecnica senza una chiara spiegazione dall'interfaccia.
- L'utente conferma senza verificare l'indirizzo spender/operator e il limite.
- Il rischio è maggiore quando l'interfaccia non mostra il spender, il limite o il tipo di autorizzazione.
Esempio: un utente collega un portafoglio a una pagina “airdrop”, fa clic su Richiedi e firma un approve illimitato per una stablecoin. Il saldo non cambia, ma successivamente, quando arrivano i fondi, il spender ritira i token tramite
Questi attacchi non richiedono un ritiro immediato. L'aggressore può attendere che il saldo cresca o che arrivi la liquidità e quindi utilizzare l'autorizzazione attiva.
I tipici schemi di phishing di approvazione mascherano la concessione di diritti come azioni familiari. Mentre lo stato allowance o operator è attivo, l'aggressore può utilizzarlo in qualsiasi momento senza la conferma del nuovo proprietario.
Indennità e
Errori comuni degli utenti: perché le approvazioni si accumulano e diventano una minaccia
Il pericolo delle approvazioni si avverte raramente al momento della firma perché approve solitamente non cambia gli equilibri. Il rischio appare più tardi, quando viene utilizzata un'autorizzazione attiva per la spesa, e diventa più forte se tali autorizzazioni rimangono su più reti e più token.
L'errore più comune: approvazioni illimitate per stablecoin e token liquidi. Al momento della firma sembrano meno passaggi, ma tecnicamente significa un grande allowance che consente al spender di spendere token
La stessa logica si applica a
Una classe separata di errori deriva dalla fiducia nel marchio e nel design visivo. L'utente si concentra sul dominio, sul logo o sul layout, ma l'autorizzazione viene sempre concessa a un indirizzo specifico — spender o operator. Se l'interfaccia viene sostituita, il disegno non modifica l'indirizzo nei parametri di firma.
Un altro errore comune è considerare il problema chiuso dopo revoke in una rete. Le approvazioni sono isolate per rete: allowance in Ethereum e allowance in Arbitrum sono record diversi in contratti diversi, quindi un'autorizzazione potrebbe rimanere attiva su un'altra rete.
Se sposti liquidità tra reti, controlla le approvazioni dopo le operazioni cross-chain: bridge e router spesso richiedono approve per un spender separato in ciascuna rete. Crypto bridge: come funzionano e quali sono più sicuri.
Le firme senza gas creano ulteriore confusione. Permessi e meccanismi simili vengono percepiti come conferme “soft”, ma il risultato è lo stesso: l’applicazione riceve la possibilità di installare un permesso che viene poi utilizzato per effettuare spese.
Gli errori diventano più pericolosi quando un portafoglio viene utilizzato contemporaneamente per l'archiviazione, il trading attivo e gli esperimenti. In questa modalità, un spender/operator non necessario crea l'accesso alle risorse che non facevano parte dell'operazione originale.
La principale minaccia delle approvazioni sono le autorizzazioni attive che rimangono nei contratti dopo il completamento di un'attività. allowance illimitato, NFT operator abilitato e autorizzazioni su più reti aumentano la quantità di risorse disponibili per la spesa senza nuove conferme.
Le autorizzazioni devono essere controllate separatamente per ciascuna rete: gli elenchi allowance e operator in Ethereum non corrispondono a Arbitrum, Optimism, Polygon o BSC, perché i record dei diritti sono archiviati nei contratti sulla rete specifica.
Dove controllare le autorizzazioni: cosa controllare esattamente e in quale ordine
La revisione delle autorizzazioni è una sequenza di passaggi suddivisi per rete e tipo di risorsa. I token ERC-20 e NFTs utilizzano meccanismi di accesso diversi, quindi devono essere analizzati separatamente e chiusi in ordine di priorità: prima gli indirizzi sconosciuti e i limiti ampi, poi i restanti permessi di lavoro.
- Identificare la rete con la maggior attività
- Le autorizzazioni non sono "globali": Ethereum, Arbitrum, Optimism, Polygon e BSC hanno elenchi di approvazione separati.
- Si comincia dalla rete dove si concentra la liquidità e dove sono avvenute le ultime transazioni.
- Controlla le approvazioni ERC-20 e riduci ciò che non è necessario
- La priorità va ai spender sconosciuti e ai allowance illimitati su stablecoin e token liquidi.
- Rimuovi le autorizzazioni inutilizzate e riduci i limiti all'importo necessario per l'operazione corrente.
- Verificare separatamente le approvazioni NFT
- Prestare particolare attenzione a
setApprovalForAll per mercati e giochi dApps. - Mantieni attivo un operator solo per il periodo in cui è veramente necessario.
- Prestare particolare attenzione a
- Verifica gli indirizzi che lasci attivi
- Abbina gli indirizzi spender/operator ai servizi attendibili in base all'indirizzo nella firma o nell'esploratore.
- Se un indirizzo non è riconoscibile, reimpostare allowance o disabilitare operator e concedere una nuova autorizzazione solo quando necessario.
| Avvicinamento | Cosa controlla | Lato forte | Limitazione |
|---|---|---|---|
| Scanner blockchain di rete | Approvazioni ERC-20 allowance e spesso NFT | Dati di rete, senza fidarsi di un'interfaccia dApp | È necessario cambiare rete e analizzare gli indirizzi |
| Servizi Revoke | Autorizzazioni token e NFT nella rete selezionata | Elenco + pulsante per resettare allowance/disabilitare operator | La copertura dipende dalla rete e dalle integrazioni |
| Portafogli con simulazione | Spesa, limiti, avvertenze prima della firma | Mostra quale indirizzo riceverà i diritti prima della conferma | Visualizzazione della diversa profondità di approvazione |
Cosa cercare in un elenco di autorizzazioni
- Sconosciuto spender o operator. Se l'indirizzo non è riconoscibile, è un candidato revoke.
- allowance illimitato sulla liquidità. Un allowance elevato aumenta l'importo di spesa disponibile.
- Autorizzazioni in L2s e sidechain. Le approvazioni potrebbero rimanere attive nelle reti in cui non effettui transazioni da molto tempo.
- NFT operator senza necessità attuali. Un operator attivo può trasferire NFTs senza nuove conferme.
- Contratti proxy e aggiornamenti. Approve è legato all'indirizzo spender, quindi un vecchio permesso rimane attivo anche se la logica cambia attraverso un aggiornamento.
Logica di revisione: reimpostare prima i allowance per gli indirizzi sconosciuti e rimuovere autorizzazioni illimitate sui token sensibili, quindi ridurre i limiti rimanenti all'importo necessario per le operazioni correnti.
La revisione delle autorizzazioni deve corrispondere alla modalità di archiviazione delle autorizzazioni: reti separate, token separati, spender/operator separati. Dare priorità a permessi sconosciuti e illimitati chiude i principali scenari di spesa senza nuove conferme.
Revoke è una transazione che imposta allowance su 0 per il proprietario→spender→coppia di token o interruttori
Come ottenere correttamente i permessi revoke: token, NFTs ed errori comuni
Revoke è una transazione on-chain che modifica allowance o disabilita un NFT operator. Di conseguenza, il contratto registra un nuovo stato: un determinato indirizzo non ha più diritto di gestire il tuo patrimonio. Revoke interrompe le spese future, ma non storna le transazioni già eseguite.
Algoritmo passo passo revoke per ERC-20
- Identificare la rete. Le approvazioni sono isolate per rete: Ethereum, Arbitrum, Optimism e altri L2s hanno elenchi di autorizzazioni separati.
- Trova il token e spender. Controlla l'indirizzo del contratto del token, il nome del token e il limite attuale allowance, in particolare per stablecoin e risorse liquide.
- Eseguire revoke. L'opzione standard è l'impostazione di allowance su 0 tramite approve(spender, 0) o l'utilizzo di un pulsante revoke in un servizio.
- Controlla il risultato. Assicurati che allowance sia diventato 0 e che l'autorizzazione non sia più visualizzata come attiva.
Algoritmo passo passo revoke per NFTs
- Apri l'elenco della raccolta operator. Cerca attivo
setApprovalForAll voci e relativi indirizzi operator. - Disabilitare operator. Lo stato deve essere impostato su falso.
- Ripetere per le collezioni di chiavi. Controlla prima le collezioni con il valore e la liquidità più elevati.
Errore comune: revoke viene eseguito in una rete mentre lo stato allowance o operator rimane attivo in un'altra. Se hai utilizzato bridge, aggregatori e multi-rete dApps, controlla le approvazioni in ogni rete separatamente.
Sfumatura ERC-20: alcuni token richiedono la sequenza approve(spender, 0) prima di impostare un nuovo allowance. In questi casi, revoke inizia reimpostando il limite.
Revoke modifica il record dei diritti nel contratto: allowance diventa 0 oppure operator viene disabilitato. Affinché revoke chiuda realmente l'accesso, è necessario eseguirlo nella rete corretta e per la coppia token→spender o raccolta→operator corretta.
Se hai concesso approve/permit o
Se hai già concesso un pericoloso approve: un rapido piano di riduzione dei danni
In questa situazione, l'ordine delle azioni è importante: prima spostare le risorse lontano dalle autorizzazioni attive, quindi reimpostare allowance e disabilitare operator e solo dopo indagare sull'origine della firma.
Se
- Sposta le risorse a un indirizzo "pulito". Un nuovo portafoglio con una nuova frase seed interrompe la connessione con le approvazioni attuali perché allowance e operator sono legati al vecchio indirizzo del proprietario.
- Autorizzazioni Revoke sull'indirizzo compromesso. Reimposta prima allowance per stablecoin e token liquidi, quindi per i token rimanenti.
- Controlla le autorizzazioni NFT. Disabilita
setApprovalForAll per operator non necessari. - Disconnetti le sessioni dApp nel portafoglio. Ciò non modifica allowance, ma rimuove le sessioni del sito attive che potrebbero richiedere un'altra firma.
- Isolare l'ambiente. Se esiste il rischio di un'estensione dannosa o di una sostituzione del sito, utilizza un altro browser o dispositivo.
Non accettare "trasferimenti di prova", "controlli di sicurezza" o "recupero fondi" suggeriti da sconosciuti. Tali richieste vengono spesso utilizzate per ottenere una nuova firma o un trasferimento diretto.
Dopo che è stata concessa un'autorizzazione pericolosa, la priorità è ridurre la quantità di risorse raggiungibili tramite allowance/operator e quindi reimpostare tali diritti con transazioni revoke. Finché i diritti restano attivi, la spesa potrà avvenire senza nuove conferme.
Prevenire il phishing di approvazione si riduce al controllo di due parametri: chi riceve il diritto (spender/operator) e quanto è ampio o ampio tale diritto (allowance o
Prevenzione: come concedere permessi senza diventare un bersaglio facile
La prevenzione del phishing di approvazione si basa sulla gestione delle autorizzazioni: separando i ruoli del portafoglio, limitando allowance e disabilitando operator una volta completata l'attività.
La maggior parte delle perdite sono legate ai permessi attivi che rimangono nei contratti una volta terminata un'operazione: allowance illimitato, un NFT abilitato e l'abitudine di confermare le firme senza controllare l'indirizzo. Questi record di diritti consentono la spesa senza nuove conferme fino al revoke.
Separazione dei ruoli del portafoglio
L'utilizzo di un indirizzo per archiviazione, scambio ed esperimenti rende qualsiasi approve fondamentale per l'intero saldo su quell'indirizzo. La separazione degli indirizzi limita la quantità di risorse esposte tramite allowance o operator. Se scegli un portafoglio “di archiviazione” a lungo termine, inizia con a Recensione del portafoglio crittografico hardware e impostare la conservazione a freddo prima del lavoro attivo DeFi.
🧩 Configurazione di base a tre indirizzi
- Conservazione (a lungo termine): capitale principale, interazioni minime dApp, nessuna approvazione attiva.
- Indirizzo operativo: attività regolare DeFi, saldo limitato, revisione allowance e operator programmate.
- Indirizzo sperimentale: lanci aerei, NFTs, nuovi progetti; il rischio è limitato all'importo memorizzato su di esso.
Ridurre l'ambito di ogni autorizzazione
Anche quando si lavora con servizi attendibili, considerare lo scenario di un errore o di una compromissione spender/operator. Per ERC-20, l'ambito del diritto è definito da allowance; per NFTs, l'ambito è definito da
- Utilizzare limiti esatti. L'indennità definisce il numero massimo di token che un spender può spendere.
- Reimposta allowance al termine dell'attività. Questo pone fine alla spesa
transferFrom . - Controllare l'indirizzo spender. L'autorizzazione è concessa all'indirizzo nei parametri della firma, non a un "sito".
- Disabilitare setApprovalForAll dopo l'attività. L'Operatore non dovrebbe rimanere attivo dopo la quotazione o una sessione di gioco.
- Non confermare per urgenza. L'urgenza viene spesso utilizzata in modo che la firma non venga controllata.
Modalità revisione: quando verificare le approvazioni
- Dopo un'operazione una tantum. Se il servizio non viene utilizzato regolarmente, reimpostare allowance o disattivare operator al termine dell'operazione.
- Per un indirizzo operativo DeFi. Con un'attività costante, esamina le approvazioni una volta ogni una o due settimane e rimuovi le autorizzazioni non necessarie.
- Per un indirizzo sperimentale. Per i nuovi dApps e gli airdrop, controlla e chiudi le autorizzazioni dopo ogni sessione.
Modello di lavoro: approve/permit concede il diritto a un indirizzo specifico, allowance definisce il limite, revoke modifica il limite a 0 o disabilita operator.
La prevenzione dell'approvazione è la gestione attiva delle autorizzazioni: la separazione degli indirizzi, i limiti esatti allowance e la disattivazione di operator dopo l'attività riducono la quantità di risorse disponibili per la spesa senza nuove conferme.
Approve consente la chiamata dei protocolli
Approve come meccanismo: punti di forza e rischi incorporati
Approve è il fondamento dell'infrastruttura DeFi: consente ai protocolli di eseguire operazioni attraverso
Il meccanismo approve è un compromesso tra il mantenimento delle risorse sul proprio indirizzo e l'automazione delle azioni del protocollo. I beni rimangono al tuo indirizzo, ma il contratto riceve il diritto di spenderli entro il allowance stabilito in approve.
✅ Punti di forza di approve
- I beni rimangono all'indirizzo del proprietario finché non vengono spesi
transferFrom . - I protocolli possono eseguire operazioni senza firma per ogni passaggio utilizzando allowance.
- L'indennità consente di limitare l'importo massimo di spesa per uno specifico spender.
- Le autorizzazioni sono verificabili on-chain e possono essere reimpostate con una transazione revoke.
❌ Rischi incorporati nelle approvazioni
- Un permesso rimane attivo fino al revoke e non dipende dalla chiusura di un sito o dalla disconnessione di un portafoglio.
- Il allowance illimitato aumenta la quantità di token disponibili per la spesa se il spender è compromesso.
- Se approve viene firmato senza controllare spender e il limite, il diritto potrebbe essere concesso all'indirizzo sbagliato.
Imposta approvazione per tutti per NFTs conferisce a un operator il diritto di trasferire l'intera collezione con un'unica azione.
Approve è un meccanismo di infrastruttura per la gestione dei diritti. È conveniente perché il trasferimento viene eseguito tramite allowance senza firme ripetute ed è rischioso perché un'autorizzazione attiva funziona fino a revoke e può essere utilizzata per spese successive.
Casi e lezioni: perché un “contratto corretto” può ancora diventare un problema
Anche quando si lavora con servizi legittimi, le approvazioni attive creano rischi: una vulnerabilità, un aggiornamento o una sostituzione del frontend diventa pericolosa se allowance è già registrato o operator è abilitato nel contratto.
La proprietà chiave delle approvazioni è l'assenza di una “vita”. Se è stata concessa un'autorizzazione, il contratto non ha bisogno di richiedere nuovamente approve: utilizza i diritti già registrati. Quindi il rischio dipende non solo dal servizio attuale, ma anche dall'elenco delle approvazioni accumulate sull'indirizzo.
🔓 Caso 1: vulnerabilità in un protocollo legittimo + approvazioni illimitate
Un utente concede approve illimitati a un protocollo e successivamente viene rilevato un bug nella logica di spesa ciò consente al contratto di spendere più token del previsto.
- Il contratto prevede già la spesa fino a allowance, quindi l'attacco non richiede la firma di un nuovo proprietario.
- Illimitato allowance aumenta l'importo della spesa fino al saldo del gettone sull'indirizzo del proprietario.
- Gli utenti che non effettuano nuove transazioni rimangono vulnerabili fino al ripristino di allowance.
Il numero illimitato approve trasforma un bug del protocollo in un rischio per l'intero saldo del token sull'indirizzo. allowance esatto limita la spesa massima e revoke termina la spesa nel modo corretto.
🧩 Caso 2: un aggiornamento del contratto proxy modifica il comportamento di accesso
I contratti aggiornabili mantengono lo stesso indirizzo, ma il codice a quell'indirizzo può cambiare dopo un aggiornamento o una compromissione della governance.
- Approve è legato all'indirizzo spender, non ad una specifica versione del codice.
- Dopo un aggiornamento, il nuovo codice potrebbe utilizzare allowance in modo diverso da quanto previsto dal proprietario.
- Il vecchio allowance rimane attivo finché non viene ripristinato da una transazione.
Quando i protocolli vengono aggiornati, le vecchie approvazioni dovrebbero essere riviste perché allowance rimane attivo sullo stesso indirizzo spender.
🧠 Caso 3: sostituzione del frontend mentre il brand rimane familiare
L'utente visita un sito familiare, ma l'interfaccia viene sostituita da DNS, annunci, CDN o estensioni dannose.
- L'aspetto visivo dell'interfaccia corrisponde a ciò che l'utente si aspetta.
- Approve o permit viene concesso a un indirizzo che non è il contratto di servizio.
- Controllando spender/operator nella firma si rileva la sostituzione; il marchio e il design no.
Fai affidamento sull'indirizzo spender/operator e sul limite allowance nella firma, non sul dominio e sul design della pagina.
🛰️ Caso 4: aggregatori e router come gateway di accesso ampio
Aggregatori e router utilizzano un spender per molti percorsi e protocolli.
- Un indirizzo spender serve molti scenari e molti token.
- Se il spender viene compromesso, il rischio si estende a tutti coloro che lo hanno concesso allowance.
- Illimitato allowance aumenta l'importo spendibile tramite questo indirizzo.
Per i router, il limite allowance definisce l'importo massimo di spesa e il normale revoke rimuove le vecchie autorizzazioni che non sono più necessarie.
🖼️ Caso 5: setApprovalForAll per NFTs rimane attivo per anni
- Questo è lo stato operator, non un limite per numero di NFTs.
- Anche senza attività, operator rimane abilitato nel contratto di raccolta.
- La compromissione di operator rende possibile il trasferimento di NFTs senza la firma di un nuovo proprietario.
Disabilitazione
Un incidente diventa possibile quando un allowance è già registrato o un operator è abilitato nel contratto. In quel momento la spesa potrà essere eseguita senza la firma del nuovo proprietario.
In pratica, gli incidenti si verificano perché i permessi rimangono dopo le operazioni completate. La revisione regolare e la disattivazione dei allowance e operator non necessari limitano la quantità di risorse disponibile per la spesa senza una nuova firma.
Le FAQ aiutano a chiarire quali firme concedono diritti e come funziona revoke e perché la spesa può avvenire senza ripetute conferme.
Domande frequenti sul phishing di approvazione, approve e revoke
Perché la gente dice "svuotato senza firma" se ho firmato qualcosa?
La firma serviva per concedere diritti, non per trasferire fondi. Dopo approve, permit o
approve illimitato è sempre un errore?
Il numero illimitato approve registra un valore molto grande in allowance. Ciò aumenta il numero massimo di token che il spender può spendere
revoke può restituire i fondi rubati?
No. Revoke cambia lo stato del contratto solo per il futuro: allowance diventa 0 o operator è disabilitato. Le transazioni già eseguite non vengono stornate.
Eliminare il portafoglio o “disconnettere il sito” rimuove le approvazioni?
No. Le autorizzazioni vengono archiviate sulla catena all'interno di token e contratti NFT. La disconnessione di un sito o l'eliminazione di un'app non modifica lo stato allowance o operator nel contratto.
Dove viene archiviato esattamente approve?
Nello stato di contratto intelligente. Per ERC-20 questo è il record allowance(proprietario, spender); per NFTs si tratta di approvazioni e operator nel contratto di ritiro.
approve può essere limitato a un importo specifico?
Sì. La chiamata approve passa il parametro amount e questo valore definisce allowance. Il spender non può spendere più degli attuali allowance permit.
Cos'è più pericoloso: approve per un token o setApprovalForAll per un NFT?
Di solito
È necessario verificare le approvazioni in L2s e nelle sidechain?
SÌ. Ciascuna rete archivia i propri record di diritti nei propri contratti. Le autorizzazioni in Ethereum e allowance in Arbitrum hanno valori diversi, quindi il controllo di una sola rete non mostra le autorizzazioni in altre reti.
Un portafoglio hardware protegge dal phishing di approvazione?
Un portafoglio hardware protegge la chiave privata e il processo di firma dal furto sul dispositivo, ma non cambia il significato dell'azione firmata. Un pericoloso approve/permit o
Le FAQ si riducono a una differenza verificabile: una firma può concedere diritti (approve/permit/
Uno sbagliato approve/permit o
Come proteggersi dal phishing approvativo e tenere sotto controllo i permessi
Le autorizzazioni sono la base della meccanica DeFi, ma gli stati allowance e operator sono esattamente ciò che consente di ritirare le risorse senza firma ripetuta se è stato concesso il diritto a un indirizzo non necessario.
Phishing di approvazione è abuso di diritti legittimi. Un approve/permit o
Per evitare di lasciare diritti attivi su un indirizzo, mantieni il controllo attraverso azioni concrete:
- Controllare l'indirizzo di accesso. La parte importante è spender/operator nella firma e nell'elenco delle approvazioni, non il marchio o il design.
- Limite allowance. Imposta un limite specifico per l'attività anziché illimitato e reimposta allowance quando il diritto non è più necessario.
- Disabilita operator per NFTs. Non andartene
setApprovalForAll abilitato al termine dell'azione. - Controlla tutte le reti. La tolleranza e operator vengono archiviati separatamente in ciascuna rete, quindi esamina ogni rete in cui è stato utilizzato un dApp.
- Indirizzi separati per ruolo. Il saldo su un indirizzo definisce l'importo massimo che può essere speso tramite diritti attivi su quell'indirizzo.
Trattare le approvazioni come diritti di accesso attivi registrati nei contratti. I limiti minimi allowance, i operator disabilitati e la revisione su tutte le reti riducono la quantità di risorse disponibili per la spesa senza una nuova firma.