Evidenze di phishing e abuso delle approvazioni

Un’approvazione può autorizzare uno spender senza spostare di per sé fondi. Confondere approvazione e perdita nasconde quale dato successivo stabilirebbe un trasferimento effettivo di asset.

Separa la sequenza proposta in dati: rappresentazione mostrata all’utente, modifica dell’autorizzazione, tentativo di spesa e movimento osservato. L’allowance ERC-20 è un permesso tecnico di spesa; un evento di approvazione non mostra da solo un trasferimento completato. Un movimento riuscito in stile transferFrom richiede esecuzione/ricevuta pertinente e riconciliazione dello stato. Un’autorizzazione basata su firma ha schema e ambito propri; non generalizzare la semantica ordinaria di approve a ogni messaggio firmato.

Preserva asset esatto, proprietario, spender, importo, rete e base temporale per un caso reale. Qui usa soltanto etichette non eseguibili su carta. Se una pagina visualizzata promette un’azione mentre un’autorizzazione stipulata ne concede un’altra, riporta tale incoerenza. Affermazioni di inganno o coercizione richiedono evidenze ammissibili su rappresentazione e contesto; un’allowance ampia è esposizione al controllo, non intento criminale automatico.

Non chiedere mai allo studente di connettere un wallet, firmare, concedere approvazione, inviare fondi o fornire seed/chiave privata per dimostrare il meccanismo. Lavora da dati depurati. La risposta a incidenti reali può richiedere competenze specifiche del contesto; questa lezione è un esercizio di lettura delle evidenze, non una procedura di transazione.

Allowance: autorizzazione tecnica di spesa per uno spender.

Approvazione: aggiornamento del permesso, distinto da movimento effettivo.

Evento di spesa: evidenze di esecuzione del movimento di asset mediante una capacità.

Conflitto di rappresentazione: azione promessa diversa dal controllo concesso.

ILLUSTRATIVE: una pagina P su carta promette «riscuoti 10 unità». Il dato R1 stipula che il proprietario W conceda allo spender S allowance 1000 per l’asset T. Il dato R2 stipula che S sposti con successo 400 T da W a D; la ricevuta R2 esiste soltanto come riga inventata dell’esercizio. L’acquisizione della pagina non identifica un operatore umano.

Cronologia dei permessi del contratto P→R1 autorizzazione→R2 movimento con importi separati 10/1000/400 e sezione di identità ignota. Nessun URL attivo o istruzione di approvazione eseguibile.

Didascalia: Sequenza fittizia depurata di approvazione; autorizzazione e movimento completato sono dati distinti.

SPECIFICATION_ONLY — la visualizzazione non è stata prodotta né sottoposta a revisione indipendente.

Nei dati didattici, R1 modifica il permesso e R2 registra un movimento di 400 unità. Il testo di riscossione di 10 unità è in conflitto con l’ambito del permesso di 1000 unità.

Non prova sito reale di phishing, firma reale, perdita effettiva del wallet, identità dell’operatore o intento criminale. R1 da solo non stabilirebbe alcun movimento; una revoca successiva non annullerebbe R2.

Chiamare trasferimento l’approvazione stessa; usare un’etichetta di permesso illimitato come prova di frode; inventare una ricevuta mancante; chiedere allo studente di firmare per verificare lo scenario.

Costruisci una sequenza a quattro colonne per P,R1,R2 e identità. Calcola l’allowance stipulata rimanente secondo l’ipotesi semplice di riduzione dell’esercizio e dichiara come cambia la conclusione se R2 è assente.

• Separa rappresentazione, approvazione e movimento.
• Lega ogni riga ad asset/proprietario/spender/rete.
• Non inventare dati di esecuzione assenti.
• Usa input offline depurati senza firme o fondi.

L’analisi dell’abuso delle approvazioni necessita sia del dato del permesso sia di evidenze del movimento, valutando separatamente affermazioni di rappresentazione e identità.

• L’approvazione non è un trasferimento.
• Un dato di spesa successivo può stabilire movimento entro il suo ambito.
• L’autorizzazione tecnica non identifica una persona né prova intento.

P13-L03

Usa lo strumento BlockAssay indicato soltanto come contesto per leggere le evidenze. Questa lezione non crea output dello strumento, sessioni di account o diritti di accesso. Esercizio offline; non firmare, distribuire, approvare o finanziare nulla.

• ERC20: Standard ERC-20 — Interfaccia dei token e semantica delle autorizzazioni di spesa; lo standard non stabilisce identità dell’emittente o sicurezza dei permessi. Limite: Soltanto documentazione del meccanismo; i valori illustrativi originali sono stipulati, non osservazioni. I dati storici hanno provenienza congelata separatamente e lacune esplicite nella raccolta.

ILLUSTRATIVE — input offline interamente fittizi; nessuna osservazione attuale.

null — nessuna osservazione reale

1

null

needs_review