Genehmigungs-Phishing: Warum Ihr Geldbeutel ohne Unterschrift geleert werden kann

📖 Warum ein Portemonnaie „ohne Unterschrift“ geleert werden kann

Genehmigungs-Phishing (oder Eis-Phishing) geht es nicht darum, eine Seed-Phrase zu stehlen und erfordert keinen Einbruch in die Wallet. Der Angriff missbraucht legitime Berechtigungsfunktionen: Der Nutzer best?tigt Approve (eine Transaktion, die das Recht aufzeichnet, Token für eine bestimmte Adresse auszugeben) oder SetApprovalForAll (Aktiviert einen operator, der alle NFTs in der Sammlung des Besitzers übertragen kann) einmal; danach erh?lt der Smart Contract das Recht, Assets ohne weitere Best?tigungen zu bewegen.

Ziel dieses Leitfadens: Erklären Sie, wie Berechtigungen funktionieren (Genehmigung ist der Akt der Rechtegewährung, allowance ist das erfasste Ausgabenlimit), brechen Sie die Hauptsache auf Genehmigungs-Phishing Szenarien, zeigen, wie gewährte Rechte in EVM-Netzwerken überprüft werden, und erklären Sie, wie der Widerruf von Berechtigungen funktioniert, sodass die Adresse spender/operator nach der Transaktion nicht mehr berechtigt ist, Vermögenswerte auszugeben.

Die größte Schwachstelle besteht hier in der Erwartung, dass für jede Ausgabe eine separate Unterschrift erforderlich ist. In einer Wallet-Schnittstelle sieht die Signatur wie ein gewöhnlicher Schritt aus („Zulassen“, „Verbinden“, „Für Austausch bestätigen“). Der Nutzer bestätigt also keine Übertragung, sondern eine Rechteeinräumung Diese werden im Vertrag gespeichert und später ohne erneutes Bestätigungsfenster genutzt.

Ein unnötiges allowance (ein im Vertrag festgelegtes Limit, das festlegt, wie viele Token ausgegeben werden dürfen) für einen Stablecoin oder einen Active setApprovalForAll (operator-Status für eine gesamte NFT-Sammlung) schafft langlebigen Zugriff auf Vermögenswerte: Token-Ausgaben durch transferFrom (eine ERC-20-Funktion, die es einem Vertrag ermöglicht, Token von der Adresse des Eigentümers innerhalb des allowance ohne neue Signatur auszugeben) oder NFT Die Übertragung durch einen operator ist jederzeit möglich, bis die Berechtigung revoked lautet.

Genehmigungs-Phishing nutzt Berechtigungserteilungen über approve/permit (Erstellen oder Ändern eines allowance) oder setApprovalForAll, kein „Hack“ des Protokolls. Eine Unterschrift reicht aus, damit ein Rechtenachweis im Vertrag erscheint, ermöglicht die spätere Verwendung von Vermögenswerten ohne Beteiligung des Eigentümers.

Eine approve/permit-Signatur oder setApprovalForAll erstellt einen Rechtedatensatz in einem Vertrag; Die Token-Entnahme oder NFT-Übertragung kann später ohne neues Bestätigungsfenster erfolgen, während die Berechtigung aktiv bleibt.

🎣 Was Genehmigungs-Phishing ist und warum seine „Ehrlichkeit“ unehrlich ist

Approval-Phishing nutzt regul?re Berechtigungsmechanismen: Die Rechtevergabe wirkt legitim, f?hrt nicht sofort zu einem Verlust von Geldern und wird deshalb im Moment der Signatur oft nicht als Risiko wahrgenommen.

Genehmigungs-Phishing ist ein Angriff, bei dem ein Benutzer dazu überredet wird, eine zu gewähren Erlaubnis (Genehmigung/allowance) zur Verwaltung von Token oder NFTs, und dieses Recht wird dann zum Abheben von Vermögenswerten genutzt. Die gefährliche Aktion wird als vertrauter Schnittstellenschritt getarnt: „Für Tausch bestätigen“, „Mint zulassen“, „Für Anspruch unterzeichnen“, „Zugang für Einzahlung gewähren“.

Im Gegensatz zum Schlüsseldiebstahl benötigt der Angreifer weder den privaten Schlüssel noch einen direkten Geldtransfer. Es reicht aus, wenn der Benutzer dies tut einmal Gewähren Sie einer bestimmten Adresse das Recht, Vermögenswerte auszugeben: ein spender für ERC-20-Tokens oder ein operator für NFTs. Danach erfolgt die Auszahlung ohne neue Wallet-Fenster und ohne wiederholte Bestätigungen durch den Besitzer.

Auf der Blockchain-Ebene sehen die Transaktionen gültig aus: Der Benutzer hat tatsächlich den Vertragsstatus geändert und Rechte an einer bestimmten Adresse gewährt. Aus diesem Grund wird die Brieftasche nicht offiziell „gehackt“: Vermögenswerte werden durch zuvor erteilte Berechtigungen und nicht durch Umgehung der Signatur verlassen.

In einfachen Worten: Bei approve handelt es sich nicht um eine Übertragung, sondern um die Gewährung von Ausgaberechten an eine bestimmte Adresse. Genehmigungs-Phishing bedeutet, dass der Benutzer dazu verleitet wird, einer vom Angreifer kontrollierten Adresse dieses Recht zu gewähren, während dies als normaler Swap-, Mint- oder Claim-Schritt dargestellt wird.

Genehmigungs-Phishing funktioniert über gültige Berechtigungen. Die Gefahr entsteht nach der Signatur, wenn ein aktives Ausgaberecht ohne Beteiligung des Eigent?mers genutzt wird.

Berechtigungen in EVM sind Aufzeichnungen von Rechten in Verträgen, keine einmaligen Aktionen; Deshalb kann approve über Monate hinweg aktiv bleiben und ohne erneute Signatur verwendet werden.

🧠 So funktionieren Berechtigungen in EVM: allowance, spender und „unendlich approve“

Eine EVM-Berechtigung ist ein Zustandseintrag in einem Token oder NFT-Vertrag, der Ihre Adresse mit einer bestimmten spender/operator-Adresse verbindet. This record defines who can spend tokens through transferFrom oder übertragen Sie NFTs als operator und es bleibt gültig, bis der Eigentümer es durch eine neue Transaktion ändert.

1. ERC-20: approve → allowance → transferFrom
   • Der Benutzer ruft an approve(spender, Betrag) und gibt die spender-Adresse an.
   • Der Token-Vertrag speichert die allowance limit – die maximale Anzahl an Token, die der spender ausgeben kann.
   • Die spender-Aufrufe transferFrom und gibt Token ohne neue Signaturen aus, bis der allowance 0 wird oder erschöpft ist.
   • Der Vertrag prüft allowance während transferFrom; Es wird nicht für jede Ausgabe die Unterschrift des Eigentümers verlangt.
2. Die Zulage ist an den Eigentümer → spender → Token gebunden
   • Die Berechtigung besteht nur für einen bestimmten Token und einen bestimmten spender.
   • Ein approve für USDT gewährt keinen Zugriff auf USDC und erstreckt sich nicht auf andere Verträge.
   • Jeder neue Token oder neue Spender erfordert ein separates Approve.
3. Unbegrenzte Genehmigung ist der maximale allowance-Wert
   • Bei unbegrenztem approve speichert der allowance den maximalen numerischen Wert.
   • Der spender erhält das Recht, Token aus diesem Vertrag innerhalb dieses Werts auszugeben, einschließlich zukünftiger Einzahlungen an die Adresse.
   • Die Berechtigung bleibt bis zu einer revoke-Transaktion aktiv, auch wenn der Dienst nicht mehr genutzt wird.
4. NFT: setApprovalForAll hat den Status operator ohne Begrenzung
   • setApprovalForAll(operator, true) Aktiviert den operator-Status für die gesamte NFT-Sammlung des Besitzers.
   • Dabei handelt es sich nicht um eine Mengen- oder Wertbeschränkung: Das Recht bleibt bestehen bis setApprovalForAll(operator, false) gesendet wird.
   • Wenn operator kompromittiert ist, kann NFTs ohne Bestätigung des neuen Eigentümers zurückgezogen werden.

EVM-Berechtigungen sind langlebige Rechteeinträge in Verträgen. Ein approve kann monatelang arbeiten, unbegrenzt erhöht das verfügbare Ausgabenlimit und setApprovalForAll Entfernt Mengenbeschränkungen für NFT operator.

Eine permit-Signatur (zum Beispiel EIP-2612) gibt einer Anwendung das Recht, allowance über eine signierte Nachricht festzulegen; Die Anwendung verwendet diese Signatur dann in einer Transaktion, die Rechte gewährt und die Aktion in einem Aufruf ausführt.

🧾 Permit, Permit2 und Nachrichtensignaturen: Wie Berechtigungen ohne separaten approve erteilt werden und warum Angreifer dies verwenden

Zusätzlich zum gewöhnlichen approve verfügt EVM über Möglichkeiten, Berechtigungen ohne separate Transaktion zu erteilen. Der Benutzer einfach signiert eine Nachricht, und die Anwendung verwendet diese Signatur in ihrer eigenen Transaktion, das sowohl das Ausgaberecht gewährt als auch die Aktion ausführt – Tauschen, Einzahlen oder Anspruch. Diese Mechaniken werden aufgerufen permit und Erweiterungen wie Permit2.

Aus UX-Sicht sieht dies nach weniger Schritten aus: Es gibt keine separate approve-Transaktion und es ist kein Gas für einen separaten approve-Aufruf erforderlich. Die technische Konsequenz ist dieselbe: Im Vertrag erscheint ein Ausgaberecht, und dieses Recht kann über einen einzelnen Vorgang hinaus aktiv bleiben, wenn die Signaturparameter eine breite Grenze oder einen langen Ablauf festlegen.

Genehmigungen und „gaslose Unterschriften“ ändern lediglich die Form der Bestätigung. Eine Nachrichtensignatur kann Zugriffsrechte auf Token oder NFTs installieren, genau wie approve, daher müssen Signaturparameter als Berechtigungserteilungen gelesen werden.

Bei typischen Genehmigungs-Phishing-Schemata wird der Benutzer dazu gebracht, approve/permit oder zu unterzeichnen setApprovalForAll Unter dem Vorwand „Claim“, „Mint“ oder „Deposit“ wird das aktive Recht dann zum Ausgeben genutzt.

🧪 Typische Genehmigungs-Phishing-Maßnahmen: Wie Sie zur „richtigen“ Signatur geführt werden

Diese Schemata nutzen vertraute Schnittstellen und Standard-Workflows, wodurch die Erteilung von Berechtigungen wie ein gewöhnlicher Serviceschritt aussieht.

Fast alle Angriffe folgen der gleichen Logik: Zuerst wird der Benutzer auf eine Seite gebracht, die wie eine dApp-Schnittstelle aussieht, dann fordert die Seite eine Signatur an, die ein Ausgaberecht oder operator-Recht gewährt, und danach wird die aktive Berechtigung verwendet, um Vermögenswerte ohne neue Bestätigungen abzuheben.

Das Hauptmerkmal ist das Fehlen einer direkten Aufforderung zum Senden einer Überweisung. Anstelle einer Übertragung fordert die Site approve/permit oder an setApprovalForAll: eine Vertragszustandsänderung, die das Recht zur Verwaltung des Vermögens des Eigentümers begründet.

1. Klon eines beliebten Dienstes
   • Eine gefälschte Domain oder ein Werbelink führt zu einer optisch ähnlichen Kopie eines DEX oder Marktplatzes.
   • Die Schnittstelle fordert approve „for swap“ bzw. an setApprovalForAll „für NFT-Auflistung“.
   • Die Signaturparameter enthalten einen spender/operator, der nicht zum eigentlichen Dienst gehört.
2. Kompromiss der offiziellen Kanäle
   • Ein Link wird im Namen des Projekts oder eines Moderators in Discord, Telegram oder X gepostet.
   • Es werden Dringlichkeitsauslöser verwendet: „Vertragsfehler“, „Mint-Migration“, „Letzte Chance“.
   • Der Link führt zu einer Seite, die approve/permit nach der Adresse des Angreifers fragt.
3. Social Engineering durch „Unterstützung“
   • Der Angreifer sendet eine private Nachricht und gibt vor, ein Service-Supporter zu sein.
   • Unter dem Vorwand der „Stornierung einer feststeckenden Transaktion“ wird eine Unterschrift verlangt.
   • In der Praxis signiert der Nutzer ein Permit oder erteilt einer Drittadresse ein Approve.
4. Ersetzung der Signaturbedeutung
   • Das Wallet-Fenster zeigt einen technischen Aufruf, ohne dass die Oberfl?che ihn klar erkl?rt.
   • Der Nutzer best?tigt, ohne die Adresse des Spenders/Operators und das Limit zu pr?fen.
   • Das Risiko ist am höchsten, wenn die Schnittstelle weder den spender noch den Limit- oder Berechtigungstyp anzeigt.

Typische Approval-Phishing-Angriffe tarnen die Gewährung von Rechten als vertraute Handlungen. Solange der Status allowance oder operator aktiv ist, kann der Angreifer ihn jederzeit verwenden, ohne dass ein neuer Eigentümer dies bestätigen muss.

Zulage und setApprovalForAll haben kein Ablaufdatum: Der Rechtedatensatz bleibt im Vertrag, bis der Eigentümer eine Transaktion sendet, die den allowance zurücksetzt oder den operator deaktiviert.

🧯 Häufige Benutzerfehler: Warum sich Genehmigungen häufen und zur Bedrohung werden

Die Gefahr von Genehmigungen ist im Moment der Unterzeichnung selten zu spüren, da approve den Saldo in der Regel nicht verändert. Das Risiko tritt später auf, wenn eine aktive Berechtigung zum Ausgeben verwendet wird, und wird größer, wenn diese Berechtigungen über mehrere Netzwerke und mehrere Token hinweg bestehen bleiben.

Die gleiche Logik gilt für setApprovalForAll für NFTs. Der Benutzer behandelt es als einmalige Aktion für die Auflistung oder Prägung, aber ein aktiver operator-Status verbleibt im Inkassovertrag und ermöglicht die Übertragung von NFT ohne Bestätigung eines neuen Eigentümers.

Eine eigene Fehlerklasse entsteht durch das Vertrauen in die Marke und das visuelle Design. Der Benutzer konzentriert sich auf die Domain, das Logo oder das Layout, die Erlaubnis wird jedoch immer einer bestimmten Adresse erteilt – spender oder operator. Wenn die Schnittstelle ersetzt wird, ändert das Design die Adresse in den Signaturparametern nicht.

Ein weiterer häufiger Fehler besteht darin, das Problem nach revoke in einem Netzwerk als geschlossen zu betrachten. Genehmigungen sind nach Netzwerk isoliert: allowance in Ethereum und allowance in Arbitrum sind unterschiedliche Datensätze in unterschiedlichen Verträgen, sodass eine Berechtigung möglicherweise in einem anderen Netzwerk aktiv bleibt.

Gaslose Signaturen sorgen für zusätzliche Verwirrung. Genehmigungen und ähnliche Mechanismen werden als „weiche“ Bestätigungen wahrgenommen, aber das Ergebnis ist dasselbe: Die Anwendung erhält die Möglichkeit, eine Berechtigung zu installieren, die dann für Ausgaben verwendet wird.

Gefährlicher werden Fehler, wenn ein Wallet gleichzeitig für Speicherung, aktiven Handel und Experimente genutzt wird. In diesem Modus erstellt ein unnötiger spender/operator Zugriff auf Assets, die nicht Teil des ursprünglichen Vorgangs waren.

Die größte Bedrohung durch Genehmigungen sind aktive Berechtigungen, die nach Abschluss einer Aufgabe in Verträgen verbleiben. Unbegrenztes allowance, ein aktiviertes NFT operator und Berechtigungen über mehrere Netzwerke hinweg erhöhen die Menge an Vermögenswerten, die für Ausgaben ohne neue Bestätigungen verfügbar sind.

Berechtigungen müssen für jedes Netzwerk separat überprüft werden: Die Listen allowance und operator in Ethereum stimmen nicht mit Arbitrum, Optimism, Polygon oder BSC überein, da Rechtedatensätze in Verträgen im jeweiligen Netzwerk gespeichert sind.

🔎 Wo Berechtigungen überprüft werden: Was genau überprüft werden soll und in welcher Reihenfolge

Die Berechtigungsüberprüfung besteht aus einer Abfolge von Schritten nach Netzwerk und Asset-Typ. ERC-20-Tokens und NFTs verwenden unterschiedliche Zugriffsmechanismen, daher müssen sie separat analysiert und in der Prioritätsreihenfolge geschlossen werden: unbekannte Adressen und breite Limits zuerst, dann die verbleibenden Arbeitsberechtigungen.

1. Identifizieren Sie das Netzwerk mit der höchsten Aktivität
   • Berechtigungen sind nicht „global“: Ethereum, Arbitrum, Optimism, Polygon und BSC verfügen über separate Genehmigungslisten.
   • Beginnen Sie mit dem Netzwerk, in dem die Liquidität konzentriert ist und in dem die letzten Transaktionen stattgefunden haben.
2. Überprüfen Sie ERC-20-Genehmigungen und reduzieren Sie Unnötiges
   • Vorrang haben unbekannte spenders und unbegrenzte allowances für Stablecoins und Liquid Token.
   • Entfernen Sie ungenutzte Berechtigungen und reduzieren Sie die Grenzwerte auf den für den aktuellen Vorgang erforderlichen Betrag.
3. Prüfen Sie die NFT-Zulassungen separat
   • Achten Sie besonders darauf setApprovalForAll für Marktplätze und Gaming dApps.
   • Halten Sie einen operator nur für den Zeitraum aktiv, in dem er wirklich benötigt wird.
4. Verify addresses you leave active
   • Ordnen Sie spender/operator-Adressen anhand der Adresse in der Signatur oder im Explorer vertrauenswürdigen Diensten zu.
   • Wenn eine Adresse nicht erkennbar ist, setzen Sie allowance zurück oder deaktivieren Sie operator und erteilen Sie nur bei Bedarf eine neue Berechtigung.

Worauf Sie in einer Berechtigungsliste achten sollten

Die Berechtigungsüberprüfung sollte mit der Art und Weise übereinstimmen, wie Berechtigungen gespeichert werden: separate Netzwerke, separate Token, separate spenders/operators. Die Priorisierung unbekannter und unbegrenzter Berechtigungen schließt die Hauptszenarien für Ausgaben ohne neue Bestätigungen aus.

Revoke ist eine Transaktion, die allowance für das Besitzer→spender→Token-Paar oder die Switches auf 0 setzt setApprovalForAll(operator) zu falsch; Nach der Netzwerkbestätigung verliert die Adresse spender/operator das Ausgaberecht.

🧹 So verwenden Sie revoke-Berechtigungen richtig: Token, NFTs und häufige Fehler

Revoke ist eine On-Chain-Transaktion, die allowance ändert oder einen NFT operator deaktiviert. Dadurch wird im Vertrag ein neuer Stand festgehalten: Eine bestimmte Adresse hat nicht mehr das Recht, Ihr Vermögen zu verwalten. Revoke stoppt künftige Ausgaben, macht aber bereits ausgeführte Transaktionen nicht rückgängig.

Schritt-für-Schritt-Algorithmus revoke für ERC-20

1. Identifizieren Sie das Netzwerk. Genehmigungen sind nach Netzwerk isoliert: Ethereum, Arbitrum, Optimism und andere L2s verfügen über separate Berechtigungslisten.
2. Suchen Sie den Token und spender. Überprüfen Sie die Token-Vertragsadresse, den Token-Namen und das aktuelle allowance-Limit, insbesondere für Stablecoins und liquide Vermögenswerte.
3. Führen Sie revoke aus. Die Standardoption besteht darin, allowance über approve(spender, 0) auf 0 zu setzen oder eine revoke-Schaltfläche in einem Dienst zu verwenden.
4. Überprüfen Sie das Ergebnis. Stellen Sie sicher, dass allowance den Wert 0 hat und die Berechtigung nicht mehr als aktiv angezeigt wird.

Schritt-für-Schritt-Algorithmus revoke für NFTs

1. Öffnen Sie die Sammlungsliste operator. Suchen Sie nach Aktiv setApprovalForAll Einträge und zugehörige operator Adressen.
2. Deaktivieren Sie operator. Der Status muss auf false geschaltet werden.
3. Wiederholen Sie diesen Vorgang für die Schlüsselübergabe. Prüfen Sie zunächst die Sammlungen mit dem höchsten Wert und der höchsten Liquidität.

Revoke ändert den Rechtedatensatz im Vertrag: allowance wird 0 oder operator wird deaktiviert. Damit revoke den Zugriff wirklich schließt, muss er im richtigen Netzwerk und für das richtige Paar Token→spender oder Sammlung→operator durchgeführt werden.

Wenn Sie approve/permit oder gewährt haben setApprovalForAll Für einen Angreifer können die Ausgaben später erfolgen, auch nachdem Sie das Guthaben aufgeladen haben. Eine klare Aktionsreihenfolge hilft dabei, zunächst Assets aus dem Bereich der aktiven Berechtigungen zu verschieben, dann allowance zurückzusetzen und operator zu deaktivieren, um den Ausgabenzugriff zu schließen.

🚨 Wenn Sie bereits ein gefährliches approve gewährt haben: ein schneller Plan zur Schadensreduzierung

In dieser Situation ist die Reihenfolge der Aktionen wichtig: Entfernen Sie zuerst Assets von aktiven Berechtigungen, setzen Sie dann allowance zurück und deaktivieren Sie operator und untersuchen Sie erst danach die Quelle der Signatur.

Wenn Genehmigungs-Phishing vermutet wird, liegt der entscheidende Punkt darin, dass die erteilten Berechtigungen möglicherweise bereits nutzbar sind. Während allowance über Null liegt oder operator aktiviert ist, können Ausgaben jederzeit eingeleitet werden, auch nachdem neue Gelder an der Adresse eingegangen sind.

Nachdem eine gefährliche Erlaubnis erteilt wurde, besteht die Priorität darin, die Menge der über allowance/operator erreichbaren Assets zu reduzieren und diese Rechte dann mit revoke-Transaktionen zurückzusetzen. Während die Rechte aktiv bleiben, können Ausgaben ohne neue Bestätigungen erfolgen.

Bei der Verhinderung von Genehmigungs-Phishing geht es darum, zwei Parameter zu kontrollieren: Wer erhält das Recht (spender/operator) und wie groß oder umfassend dieses Recht ist (allowance bzw setApprovalForAll).

🛡️ Prävention: So erteilen Sie Berechtigungen, ohne zum leichten Ziel zu werden

Die Verhinderung von Genehmigungs-Phishing basiert auf der Berechtigungsverwaltung: Trennung der Wallet-Rollen, Beschränkung von allowance und Deaktivierung von operator nach Abschluss der Aufgabe.

Die meisten Verluste hängen mit aktiven Berechtigungen zusammen, die nach Abschluss einer Operation in Verträgen verbleiben: unbegrenztes allowance, aktiviertes NFT operator und die Gewohnheit, Unterschriften zu bestätigen, ohne die Adresse zu überprüfen. Diese Rechtedatensätze ermöglichen Ausgaben ohne neue Bestätigungen bis revoke.

Trennung der Wallet-Rollen

Durch die Verwendung einer Adresse für Speicherung, Handel und Experimente ist jedes approve entscheidend für den gesamten Saldo dieser Adresse. Durch die Trennung von Adressen wird die Menge der über allowance oder operator offengelegten Vermögenswerte begrenzt. Wenn Sie sich langfristig für eine „Speicher“-Wallet entscheiden, beginnen Sie mit a Überprüfung der Hardware-Krypto-Wallet und richten Sie vor der aktiven Arbeit einen Kühlraum ein.

Reduzierung des Umfangs jeder Berechtigung

Auch wenn Sie mit vertrauenswürdigen Diensten arbeiten, sollten Sie das Szenario eines spender/operator-Fehlers oder einer Kompromittierung in Betracht ziehen. Für ERC-20 wird der Umfang des Rechts durch allowance definiert; Für NFTs wird der Bereich definiert durch setApprovalForAll Status.

Überprüfungsmodus: Wann werden Genehmigungen überprüft?

1. Nach einer einmaligen Operation. Wenn der Dienst nicht regelmäßig genutzt wird, setzen Sie allowance zurück oder deaktivieren Sie operator, nachdem der Vorgang abgeschlossen ist.
2. Für eine betriebsbereite DeFi-Adresse. Überprüfen Sie bei konstanter Aktivität die Genehmigungen alle ein bis zwei Wochen und entfernen Sie unnötige Berechtigungen.
3. Für eine experimentelle Adresse. Überprüfen und schließen Sie für neue dApps- und Airdrops-Berechtigungen nach jeder Sitzung.

Bei der Genehmigungsverhinderung handelt es sich um eine aktive Berechtigungsverwaltung: Adresstrennung, genaue allowance-Grenzwerte und die Deaktivierung von operator nach der Aufgabe verringern die Menge der für Ausgaben ohne neue Bestätigungen verfügbaren Vermögenswerte.

Approve lässt Protokolle aufrufen transferFrom ohne Unterschrift für jeden Vorgang; Der gleiche Mechanismus bedeutet, dass eine aktive Erlaubnis später für Ausgaben verwendet werden kann, wenn sie einer unnötigen Adresse erteilt wurde.

⚖️ Approve als Mechanismus: Stärken und eingebaute Risiken

Approve ist eine Grundlage der DeFi-Infrastruktur: Es ermöglicht Protokollen die Durchführung von Operationen transferFrom basiert auf allowance, macht aber den Eigentümer für die spender-Adresse und das allowance-Limit verantwortlich.

Der approve-Mechanismus ist ein Kompromiss zwischen der Aufbewahrung von Vermögenswerten an Ihrer eigenen Adresse und der Automatisierung von Protokollaktionen. Vermögenswerte bleiben an Ihrer Adresse, aber der Vertrag erhält das Recht, sie innerhalb des in approve festgelegten allowance auszugeben.

Approve ist ein Infrastrukturmechanismus zur Rechteverwaltung. Dies ist praktisch, da die Übertragung über allowance ohne wiederholte Signaturen ausgeführt wird, und riskant, da eine aktive Berechtigung bis revoke gültig ist und für spätere Ausgaben verwendet werden kann.

📚 Fälle und Lehren: Warum ein „richtiger Vertrag“ immer noch zum Problem werden kann

Selbst bei der Arbeit mit legitimen Diensten stellen aktive Genehmigungen ein Risiko dar: Eine Schwachstelle, ein Upgrade oder ein Frontend-Austausch wird gefährlich, wenn allowance bereits erfasst ist oder operator im Vertrag aktiviert ist.

Die zentrale Eigenschaft von Zulassungen ist das Fehlen einer „Lebensdauer“. Wenn eine Erlaubnis erteilt wurde, muss der Vertrag approve nicht erneut anfordern: Er nutzt die bereits erfassten Rechte. Daher hängt das Risiko nicht nur von der aktuellen Leistung ab, sondern auch von der Liste der an der Adresse gesammelten Genehmigungen.

In der Praxis kommt es zu Vorfällen, weil Berechtigungen nach abgeschlossenen Vorgängen bestehen bleiben. Durch regelmäßige Überprüfung und Deaktivierung unnötiger allowances und operators wird die Menge der Vermögenswerte begrenzt zur Ausgabe ohne neue Unterschrift verfügbar.

Eine Verwechslung approve/permit oder setApprovalForAll gibt einer externen Adresse das Recht, Token über allowance auszugeben oder NFTs als operator zu übertragen; Während die Berechtigung aktiv ist, fordert das Wallet keine neue Signatur für die Ausgabe selbst an.

✅ So schützen Sie sich vor Approval-Phishing und behalten die Kontrolle über Berechtigungen

Berechtigungen sind die Grundlage der DeFi-Mechanik, aber der allowance- und der operator-Status ermöglichen genau das Abheben von Vermögenswerten ohne erneute Unterschrift, wenn das Recht einer unnötigen Adresse gewährt wurde.