So überprüfen Sie die Wallet-Sicherheit, bevor Sie eine Verbindung zu einer Website herstellen

Überprüfen Sie die Integrität des Wallet-Verbindungsprotokolls

1. Bestätigen Sie, dass die dApp EIP-1193-konforme Anbieterinjektion anstelle veralteter window.ethereum-Hacks verwendet. Ältere Injektionsmethoden legen den Wallet-Status ohne Zustimmung des Benutzers offen.

2. Untersuchen Sie die Browser-Entwicklerkonsole auf nicht vertrauenswürdige Skriptinjektionen, die versuchen, window.ethereum zu überschreiben oder Anbieterereignisse zu kapern.

3. Überprüfen Sie, ob die Site strenge Content Security Policy-Header durchsetzt, die Inline-Skripte und nicht autorisierte Domänen daran hindern, Wallet-bezogene Logik auszuführen.

4. Stellen Sie sicher, dass keine Analyse- oder Werbe-SDKs von Drittanbietern Zugriff auf Web3-Anbieter anfordern – ein solches Verhalten verstößt gegen das Berechtigungsmodell von MetaMask und weist auf eine böswillige Absicht hin.

5. Stellen Sie sicher, dass die dApp eth_requestAccounts nicht vor einer vom Benutzer initiierten Aktion aufruft, da eine vorzeitige Offenlegung des Kontos dazu führen kann, dass Phishing-fähige Wallets die Verbindung blockieren.

Analysieren Sie die Domänenauthentifizierung und die Zertifikatsgültigkeit

1. Geben Sie die Domain manuell in die Adressleiste ein, anstatt auf Links von Telegram, Discord oder Twitter zu klicken – über 67 % der Wallet-Entzugsvorfälle gehen auf gefälschte Social-Media-Weiterleitungen zurück.

2. Bestätigen Sie, dass das TLS-Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde und mit dem genauen Domänennamen übereinstimmt, ohne Platzhaltermehrdeutigkeit oder nicht übereinstimmende alternative Betreffnamen.

3. Überprüfen Sie das Domain-Registrierungsdatum über WHOIS. Neu registrierte Domains, die DeFi-Schnittstellen hosten, bergen statistisch gesehen ein höheres Risiko für Rug Pulls oder Front-End-Kompromittierungen.

4. Verwenden Sie ENS-Suchtools, um zu überprüfen, ob die Domain in einen verifizierten Ethereum Name Service-Datensatz aufgelöst wird, der mit bekannten Projektadressen verknüpft ist.

5. Achten Sie auf visuelle Indikatoren wie das grüne Schlosssymbol und das Fehlen von „Nicht sicher“-Warnungen – Warnungen zu gemischten Inhalten oder Unterbrechungen der Zertifikatskette machen die Vertrauensannahmen der Wallet ungültig.

Überprüfen Sie das Verhalten des Wallet-Anbieters während der Initialisierung

1. Beobachten Sie, ob die Wallet-Erweiterung explizite Erlaubnisaufforderungen anzeigt, bevor Konten offengelegt werden – stille Auto-Connect-Flows umgehen die Benutzeragentur und sind Warnsignale.

2. Überwachen Sie die Registerkarte „Netzwerk“ auf unerwartete RPC-Aufrufe an nicht standardmäßige Endpunkte wie rpc.uniswap.org oder api.metamask.io – diese Proxys werden häufig über kompromittierte Relays weitergeleitet.

3. Stellen Sie sicher, dass die dApp keine Wallet-Anbieter-Referenzen im globalen Bereich oder im lokalen Speicher speichert oder zwischenspeichert, was Sitzungs-Hijacking beim Neuladen von Seiten ermöglicht.

4. Überprüfen Sie, ob die Website versucht, bestimmte Wallet-Typen zu erkennen (z. B. „if (window.trustWallet)“) und eine veränderte UI-Logik bereitstellt – dies deutet auf eine gezielte Exploit-Vorbereitung hin.

5. Stellen Sie sicher, dass die Trennfunktion eine vollständige Bereinigung des Anbieters auslöst, einschließlich der Entfernung von Ereignis-Listenern und der Aufhebung zwischengespeicherter Anbieterobjekte.

Bewerten Sie die Sicherheitsvorkehrungen für die Transaktionssignierung

1. Bestätigen Sie, dass alle Transaktionsanfragen rohe Hex-Daten, Gasschätzungen und Empfängeradressen in einem für Menschen lesbaren Format anzeigen, bevor Sie zur Signatur aufgefordert werden – verschleierte Felder weisen auf eine böswillige Nutzdatenmaskierung hin.

2. Testen Sie, ob die dApp das Signieren beliebiger Nachrichten ohne klaren Kontext ermöglicht – diese Funktion wurde bei mehreren Wallet-Imitierungsangriffen missbraucht.

3. Stellen Sie sicher, dass Approve()-Aufrufe genaue Token-Zulassungsgrenzen enthalten und nicht standardmäßig uint256.max verwenden, es sei denn, dies ist durch eine Benutzeraktion ausdrücklich gerechtfertigt.

4. Suchen Sie nach doppelten oder verschachtelten Transaktionsanfragen, die durch einzelne UI-Aktionen ausgelöst wurden – Race-Condition-Exploits haben durch wiederholte Genehmigungen zu einer Belastung der Geldbörsen geführt.

5. Stellen Sie sicher, dass die Site keine Transaktionen mit eth_sendTransaction ohne Benutzerbestätigung vorab lädt – dies verstößt gegen EIP-1102 und ermöglicht stille Geldtransfers.

Überprüfen Sie die Vertragsinteraktionsmuster in der Kette

1. Verwenden Sie Blockscout oder Etherscan, um zu überprüfen, ob die bereitgestellten Vertragsadressen mit den in der offiziellen Dokumentation veröffentlichten und in der Kette überprüften Adressen übereinstimmen.

2. Bestätigen Sie, dass Proxy-Verträge transparente Upgrade-Muster mit unveränderlichen Implementierungsslots verwenden – undurchsichtige Proxys verdecken Codeänderungen nach der Bereitstellung.

3. Überprüfen Sie, ob die dApp mit bekannten bösartigen Adressen interagiert, die von Immunefi- oder OpenZeppelin Defender-Überwachungs-Feeds gekennzeichnet werden.

4. Überprüfen Sie, ob Multisig- oder Timelock-Mechanismen kritische Funktionen wie Treasury-Abhebungen oder Oracle-Updates steuern – das Fehlen weist auf ein Zentralisierungsrisiko hin.

5. Überprüfen Sie, ob das Frontend Vertrags-ABI dynamisch von IPFS oder zentralen Servern abruft – manipulierte ABIs können Funktionsparameter beim Signieren falsch darstellen.

Häufig gestellte Fragen

F: Kann ich einer dApp vertrauen, die MetaMask automatisch und ohne Aufforderung lädt? Das automatische Laden ohne explizite Benutzerinitiierung verstößt gegen EIP-1102 und deutet darauf hin, dass die Website möglicherweise versucht, Wallet-Konten im Hintergrund aufzulisten.

F: Ist es sicher, mein Wallet über Cloudflare Turnstile anstelle von reCAPTCHA mit einer Website zu verbinden? Cloudflare Turnstile verbessert die Wallet-Sicherheit nicht von Natur aus – seine Anwesenheit validiert weder die Vertragsintegrität noch verhindert es Front-End-Manipulationen von Transaktionsnutzdaten.

F: Gewährleistet HTTPS die Wallet-Sicherheit bei der Verbindung mit einer dezentralen Anwendung? HTTPS sichert nur die Kommunikation auf der Transportschicht; Es bietet keinerlei Schutz vor böswilliger Vertragslogik, manipulierten ABI-Dateien oder kompromittierten Front-End-JavaScript-Bundles.

F: Was passiert, wenn ich einen symbolischen Zuschuss zu einem Vertrag genehmige, der später auf einer schwarzen Liste steht? Sobald der Vertrag genehmigt wurde, behält er sein Ausgaberecht, bis er manuell widerrufen wird. Durch den Blacklist-Status werden bestehende Zulagen nicht rückwirkend storniert oder die Bewegung von Mitteln verhindert.