Preuves de phishing et d’abus d’autorisation

Une autorisation peut habiliter un dépensier sans déplacer de fonds. Confondre autorisation et perte masque l’enregistrement ultérieur qui établirait un transfert réel.

Séparez représentation destinée à l’utilisateur, modification d’autorisation, tentative de dépense et mouvement observé. L’allocation ERC-20 est une permission technique ; un événement d’approbation seul ne montre pas un transfert achevé. Un mouvement réussi de type transferFrom exige exécution/reçu pertinent et rapprochement d’état. Une autorisation par signature a son propre schéma et périmètre ; ne généralisez pas approve ordinaire à tous les messages signés.

Conservez actif, propriétaire, dépensier, montant, réseau et base temporelle exacts pour un cas réel. Ici, seulement des étiquettes papier non exécutables. Si une page promet une action et l’autorisation stipulée en accorde une autre, rapportez l’incohérence. Tromperie ou coercition exige preuves admissibles de représentation et contexte ; une large allocation expose un contrôle sans prouver automatiquement une intention criminelle.

Ne demandez jamais connexion de portefeuille, signature, autorisation, envoi de fonds ou phrase de récupération/clé privée pour démontrer le mécanisme. Utilisez des enregistrements assainis. Répondre à un incident réel peut nécessiter expertise contextuelle ; cette leçon est une lecture de preuves, pas une procédure de transaction.

Allocation : autorisation technique de dépense pour un dépensier.

Approbation : mise à jour de permission, distincte du mouvement réel.

Événement de dépense : preuve d’exécution que des actifs ont bougé sous une capacité.

Conflit de représentation : action promise différente du contrôle accordé.

ILLUSTRATIVE : page papier P promet « réclamer 10 unités ». R1 stipule que propriétaire W accorde à S allocation 1000 pour T. R2 stipule que S déplace avec succès 400 T de W vers D ; reçu R2 n’existe que comme ligne inventée. La capture n’identifie pas d’opérateur humain.

Chronologie de permissions P→R1 autorisation→R2 mouvement avec montants distincts 10/1000/400 et voie d’identité inconnue. Aucun URL actif ni instruction exécutable d’approbation.

Caption: Séquence fictive assainie ; autorisation et mouvement accompli sont des enregistrements distincts.

SPECIFICATION_ONLY — le visuel rendu n’a pas été produit ni examiné indépendamment.

Dans l’exemple, R1 modifie permission et R2 enregistre mouvement de 400 unités. Texte de réclamation de 10 unités contredit périmètre de permission de 1000 unités.

Aucun site réel de phishing, signature réelle, perte réelle, identité d’opérateur ou intention criminelle n’est prouvé. R1 seul n’établit aucun mouvement ; une révocation ultérieure n’annulerait pas R2.

Appeler approbation un transfert ; utiliser permission illimitée comme preuve de fraude ; inventer reçu manquant ; demander une signature pour tester.

Construisez quatre colonnes pour P,R1,R2 et identité. Calculez allocation restante selon réduction simple stipulée et indiquez comment la conclusion change sans R2.

• Séparer représentation, approbation et mouvement.
• Lier chaque ligne à actif/propriétaire/dépensier/réseau.
• Ne pas inventer les exécutions absentes.
• Utiliser données assainies hors ligne sans signatures ni fonds.

L’analyse d’abus d’autorisation exige permission et preuves de mouvement ; représentation et identité s’évaluent séparément.

• Approbation n’est pas transfert.
• Une dépense ultérieure peut établir mouvement dans son périmètre.
• Autorisation technique n’identifie pas humain ni ne prouve intention.

P13-L03

Utilisez l’outil BlockAssay nommé uniquement comme contexte de lecture des preuves. Cette leçon ne crée aucune sortie d’outil, session de compte ni droit d’accès. Exercice hors ligne ; ne signez, ne déployez, n’approuvez et ne financez rien.

• ERC20: Norme ERC-20 — Interface du token et sémantique des autorisations ; la norme n’établit ni l’identité de l’émetteur ni la sécurité des permissions. Limite : Documentation du mécanisme uniquement ; les valeurs illustratives originales sont stipulées, pas observées. Les enregistrements historiques disposent d’une provenance figée séparément et de lacunes de collecte explicites.

ILLUSTRATIVE — entrées hors ligne entièrement fictives ; aucune observation actuelle.

null — aucune observation réelle

1

null

needs_review