---
title: "Address poisoning"
description: "L'address poisoning inserisce un destinatario somigliante nella cronologia delle transazioni o in un'altra interfaccia dall'aspetto affidabile, affinché un pagamento successivo venga copiato verso l'attaccante; sfrutta la verifica del destinatario senza modificare l'indirizzo reale né rubarne la chiave."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Address poisoning
> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.
## Risposta diretta
L'address poisoning è una frode basata sulla sostituzione del destinatario. L'attaccante genera un indirizzo diverso, il cui prefisso e suffisso visibili somigliano a quelli di un destinatario fidato, quindi lo inserisce nella cronologia delle transazioni o in un'altra interfaccia dall'aspetto affidabile. Confida che un mittente copi in seguito quell'indirizzo somigliante e firmi un pagamento valido a suo favore. L'attacco non modifica l'indirizzo legittimo, non ne viola la chiave privata e non induce il consenso a deviare il trasferimento.
Il record inserito può derivare da una vera transazione di un asset nativo, da un trasferimento di token di valore zero conforme allo standard o da un log emesso da un altro contratto di token. Le pagine di attività di wallet ed explorer sono viste derivate: una riga etichettata «inviato» può provenire dai campi di un evento, non da una transazione esterna firmata dall'indirizzo `from` visualizzato. Occorre verificare separatamente mittente e destinazione della transazione esterna, contratto chiamato, contratto che emette l'evento, campi indicizzati ed effettive variazioni dei saldi.
Il checksum ERC-55 aiuta a rilevare alcuni errori di digitazione accidentali, ma un indirizzo diverso dell'attaccante può essere sintatticamente valido e avere un checksum corretto. I normali indirizzi EVM di 20 byte, inoltre, non identificano la chain prevista, l'asset, il ruolo del destinatario, il memo di deposito o la chiamata al contratto. Un'istruzione di pagamento sicura vincola tutti questi elementi alla destinazione completa.
## Come funziona
L'attaccante osserva un modello di pagamento pubblico e cerca un vanity address che corrisponda ai caratteri mostrati in forma troncata dal wallet. Far corrispondere determinati caratteri esadecimali non clona un account: i byte non visibili restano diversi e l'attaccante controlla la nuova chiave. Un trasferimento minimo può inserire quell'indirizzo reale nella cronologia. Separatamente, ERC-20 richiede che i trasferimenti di valore zero siano trattati come trasferimenti normali ed emettano `Transfer`; pertanto, un record di valore zero non dimostra da solo falsificazione, compromissione, autorizzazione o perdita economica.
Un contratto di token malevolo può anche emettere un proprio log `Transfer(victim, lookalike, 0)`. Quel log è un dato reale della ricevuta attribuibile al contratto emittente, ma non è un evento del contratto canonico dell'asset e non dimostra che la vittima abbia firmato la transazione esterna. Un indicizzatore che classifica l'attività dai topic degli eventi senza sufficiente contesto del contratto e della chiamata può comunque mostrare un'ingannevole riga in uscita.
Il controllo decisivo è l'intento finale di pagamento. Deve vincolare chain e rete, asset nativo o esatto contratto del token, indirizzo completo e tipo del destinatario, importo e unità raw, nonché eventuali calldata, memo, destination tag o periodo di validità. Gli indirizzi di deposito di exchange, bridge, proxy e percorsi monouso possono diventare obsoleti o richiedere più di un indirizzo. Malware della clipboard e codici QR compromessi sono attacchi distinti, ma la stessa verifica della destinazione completa rileva la sostituzione prima della firma.
Nomi e pagamenti di prova sono controlli di supporto, non prove d'identità. Risolvere un nome ENS per la chain e il record previsti al momento della firma; se viene mostrato un nome inverso, eseguire la risoluzione diretta verso lo stesso indirizzo. Una piccola prova aiuta solo se il destinatario la conferma in modo indipendente e il pagamento principale riutilizza la stessa destinazione fissata. Copiare nuovamente dalla cronologia elimina tale protezione.
Utilizzare questo processo:
1. Fissare chain, rete, asset ed esatto contratto del token, tipo di destinatario, formato dell'indirizzo, importo e qualsiasi memo, tag, calldata, versione o scadenza ricavati da una fonte indipendente autenticata.
2. Risolvere una volta nome o QR, validarne formato e checksum e vincolare tutti i byte della destinazione alla chain prevista; confermare mediante risoluzione diretta ogni nome inverso invece di trattare un'etichetta come identità.
3. Confrontare la destinazione con un'allowlist controllata, una rubrica o una fattura firmata, mai con la cronologia; richiedere approvazione indipendente o doppia per un destinatario nuovo o sostanzialmente modificato.
4. Decodificare l'esatta transazione non firmata: distinguere il `to` nativo da un contratto di token o bridge e verificare nella calldata destinatario, token, importo raw, approvazione, deadline e semantica della destinazione.
5. Quando opportuno, inviare una piccola prova alla destinazione fissata e ottenere conferma indipendente dal destinatario; non copiare nuovamente un indirizzo dalla cronologia per il pagamento principale.
6. Firmare il trasferimento principale solo dal record verificato, confrontare destinazione e importo completi su un display affidabile, quindi verificare ricevuta, contratto emittente, log e variazioni dei saldi sulla chain corretta.
7. Se si sospetta poisoning o un invio errato, interrompere i pagamenti successivi, conservare hash e prove e contattare tempestivamente il servizio destinatario, l'emittente o le autorità quando pertinente; considerare congelamento, restituzione e recupero condizionali, mai certi.
## Esempi
- **Il troncamento nasconde la differenza.** L'indirizzo legittimo `0x12ab1111111111111111111111111111111189ef` e quello dell'attaccante `0x12ab9999999999999999999999999999999989ef` sono entrambi visualizzati come `0x12ab...89ef`. Condividono `4 + 4 = 8` caratteri esadecimali visibili, ma differiscono in tutti i `32` caratteri centrali. Confrontare solo le estremità visualizzate produce una falsa corrispondenza; confrontare tutti i byte no.
- **Lavoro della ricerca vanity.** Far corrispondere `k = 8` caratteri esadecimali scelti richiede un lavoro atteso di `16^8 = 4,294,967,296` candidati. A un'ipotetica velocità di `50,000,000 candidates/s`, il tempo atteso è `4,294,967,296 / 50,000,000 = 85.89934592 s`. Ciò illustra uno spazio di ricerca, non un tempo di esecuzione promesso o una soglia di avviso del wallet.
- **Log rispetto allo stato.** Un contratto di token emette `Transfer(victim, lookalike, 0)`. Il saldo della vittima passa da `250,000.000000` a `250,000.000000`, quindi la variazione è `0.000000`; un indice delle attività può comunque mostrare una riga di trasferimento. Verificare contratto emittente e autorizzazione della chiamata: la riga da sola non dimostra né movimento di valore né firma della vittima.
- **Una prova deve fissare la destinazione.** Una tesoreria pianifica `50,000 USDC`, invia `1 USDC` a un indirizzo verificato, riceve conferma indipendente e invia `49,999 USDC` dallo stesso record fissato: `1 + 49,999 = 50,000 USDC`. Se il personale ricopia dalla cronologia un indirizzo somigliante per la seconda parte, la prova non protegge più il pagamento di `49,999 USDC`.
## Rischi
- Un mittente copia un indirizzo somigliante da una cronologia avvelenata.
- Un'interfaccia troncata nasconde i caratteri centrali differenti.
- Un prefisso o suffisso vanity viene scambiato per identità del destinatario.
- Un trasferimento ERC-20 di valore zero crea una riga di cronologia ingannevole.
- Un token contraffatto o il suo log viene scambiato per attività dell'asset canonico.
- Un indicizzatore classifica male i campi degli eventi o li corregge troppo tardi.
- Nome, simbolo o icona di un token spam imita un asset fidato.
- Un malware della clipboard sostituisce un indirizzo verificato prima della firma.
- Una rubrica locale o sincronizzata è avvelenata o obsoleta.
- Un'allowlist vincola chain, asset, ruolo o versione dell'indirizzo errati.
- Un avviso di checksum non valido o mancante viene ignorato.
- Un checksum valido viene scambiato per prova dell'identità del destinatario.
- La risoluzione ENS cambia, usa il coin type sbagliato o è obsoleta.
- Un nome inverso viene visualizzato senza conferma mediante risoluzione diretta.
- Dopo un pagamento di prova si copia di nuovo da una fonte non affidabile.
- Indirizzo di deposito, rete, memo o tag di un exchange è errato o scaduto.
- Destinazione e calldata richiesta da bridge, proxy o contratto sono fraintese.
- Un firmatario controlla solo testo troncato, persino su un dispositivo hardware.
- Un trasferimento al destinatario sbagliato diventa canonico prima dell'intervento.
- La vittima fa affidamento sul congelamento discrezionale dell'emittente o su una recovery scam.
## Errori comuni
- **L'address poisoning significa che wallet, chiave o blockchain sono stati violati.** L'attacco usuale sfrutta la selezione del destinatario mentre crittografia e consenso validi eseguono l'intento firmato errato.
- **Una riga di valore zero deve essere una transazione on-chain falsa.** Trasferimenti conformi e log reali possono avere valore zero; verificarne origine ed effetto sullo stato.
- **Estremità corrispondenti più checksum dimostrano il destinatario.** Un altro indirizzo valido può corrispondere nei caratteri visibili e avere un proprio checksum valido.
- **Una prova riuscita protegge automaticamente il trasferimento successivo.** La protezione si perde se il pagamento principale non riutilizza la destinazione fissata e confermata.
- **Wallet, validatore o emittente del token possono sempre annullare il pagamento.** Poteri e cooperazione per il recupero dipendono da asset, servizio, giurisdizione, prove e tempistica.
## Argomenti correlati
- [Truffe di phishing](/it/crypto/phishing-scam/)
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)
- [Wallet di criptoattività](/it/crypto/wallet/)
## Fonti
- [Address poisoning scams](https://support.metamask.io/stay-safe/protect-yourself/wallet-and-hardware/address-poisoning-scams/) - MetaMask Help Center (consultato: 2026-08-13)
- [Anatomy of an Address Poisoning Scam](https://www.chainalysis.com/blog/address-poisoning-scam/) - Chainalysis (consultato: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [ERC-55: Mixed-case checksum address encoding](https://eips.ethereum.org/EIPS/eip-55) - Ethereum Improvement Proposals (consultato: 2026-08-13)
- [Transactions](https://ethereum.org/en/developers/docs/transactions/) - ethereum.org (consultato: 2026-08-13)
- [Resolution](https://docs.ens.domains/resolution/) - ENS Documentation (consultato: 2026-08-13)
- [Frequently asked questions](https://ethereum.org/en/community/support/faq/) - ethereum.org (consultato: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (consultato: 2026-08-13)
Source: https://wiki.fcontext.com/it/crypto/address-poisoning/index.mdx