Front-End-Hijacks: wenn sich die echte Website gegen dich wendet

Die meisten Ratschläge gegen Phishing laufen auf eine Regel hinaus: Prüfe, ob du auf der echten Seite bist. Tippe die Adresse selbst ein, nutze Lesezeichen, ignoriere Links in Nachrichten. Das ist ein guter Rat – aber er hat einen blinden Fleck. Manchmal liefert die echte Seite unter der echten Adresse plötzlich etwas Bösartiges aus.

Genau das ist ein Front-End-Hijack. Die Smart Contracts hinter einer dApp können vollkommen sicher sein, während die Website, über die du sie erreichst, unbemerkt ausgetauscht wurde – und jede Transaktion, die sie dich signieren lässt, darauf ausgelegt ist, deine Wallet zu leeren.

Die Website ist etwas anderes als das Protokoll

Eine dezentrale Anwendung besteht aus zwei Hälften:

• Den Contracts auf der Blockchain, die Guthaben verwahren und die Regeln durchsetzen.
• Dem Front-End – der Website –, das Daten liest, Transaktionen zusammenstellt und sie zum Signieren an deine Wallet schickt.

Die Contracts sind in der Regel auditiert, öffentlich und schwer zu ändern. Das Front-End ist eine gewöhnliche Website auf gewöhnlicher Infrastruktur, und es entscheidet genau, was dir zum Signieren vorgelegt wird. Kontrolliert ein Angreifer die Website, muss er die Contracts gar nicht anrühren. Er muss nur erreichen, dass du seine Transaktion statt der echten signierst.

Wie Front-Ends gekapert werden

• DNS-Hijacking. Der Angreifer übernimmt die Einstellungen der Domain – oft über den Domain-Registrar oder das Konto, das sie verwaltet – und lässt die echte Adresse auf seinen eigenen Server zeigen. Die URL in deinem Browser stimmt; die Seite nicht.
• Kompromittiertes Hosting oder Deployment. Ein Angreifer mit Zugriff auf das Hosting, die Build-Pipeline oder die Deployment-Schlüssel des Projekts spielt eine veränderte Version der Seite ein.
• Bösartige Abhängigkeiten. Ein Skript oder eine Bibliothek eines Drittanbieters, die die Seite lädt – Analytics, eine UI-Komponente, ein Paket zur Wallet-Verbindung –, wird kompromittiert, und jede Seite, die sie nutzt, liefert fortan den Code des Angreifers aus.
• Eingeschleuste Skripte. Eine Schwachstelle erlaubt es einem Angreifer, Code in eine ansonsten legitime Seite einzufügen.

In jedem Fall wirkt der Besuch völlig normal. Gleiche URL, gleiches Design, gleicher Ablauf – bis zur Transaktionsanfrage.

Wie der Angriff aussieht

Ein gekapertes Front-End zielt meist auf eine von wenigen besonders lohnenden Anfragen ab:

• Unbegrenzte Token-Freigaben an eine Adresse des Angreifers, getarnt als normaler Schritt „Zum Fortfahren freigeben“.
• „Freigabe für alle“ bei NFTs, präsentiert als Listing oder Claim.
• Off-Chain-Signaturen – Permits oder Marktplatz-Orders –, die später eingereicht werden können, um Guthaben ohne weitere Abfrage zu bewegen.
• Direkte Überweisungen, getarnt als Einzahlungen, Claims oder Migrationen.

Das Warnsignal ist ein Widerspruch zwischen dem, was du tust, und dem, was du signieren sollst. Ein kleiner Swap sollte keine unbegrenzte Freigabe an eine Adresse erfordern, die du nicht kennst. Eine Belohnung abzuholen sollte nicht erfordern, alles zu überweisen.

So schützt du dich

Einen gekaperten Server erkennst du nicht, indem du dir die Seite ansiehst. Deine Verteidigung ist der Signierschritt, denn dort muss die Absicht des Angreifers sichtbar werden.

• Lies jede Anfrage in deiner Wallet, nicht auf der Website. Die Seite kann alles behaupten; die Wallet zeigt, was du tatsächlich signierst.
• Prüfe bei Freigaben den Spender und den Betrag. Unbekannte Adressen und unbegrenzte Freigaben verdienen ein klares Stopp.
• Sei misstrauisch bei plötzlichen Änderungen im Ablauf. Eine Seite, die bei einem bestimmten Schritt nie eine Signatur oder Freigabe verlangt hat und es plötzlich tut, ist ein Warnzeichen.
• Nutze Simulation, wo du sie hast. Vorab anzusehen, was eine Transaktion bewirkt, entlarvt Anfragen, deren tatsächliche Wirkung von ihrer Beschriftung abweicht.
• Verfolge Ankündigungen. Projekte, die eine Kompromittierung ihres Front-Ends bemerken, warnen in der Regel schnell über ihre offiziellen Kanäle. Wenn sich etwas falsch anfühlt, prüfe es vor dem Signieren.
• Widerrufe im Nachhinein, wenn du unsicher bist. Wenn du in einem Zeitraum, in dem eine Seite kompromittiert war, etwas freigegeben hast, widerrufe die Freigabe sofort.

Das ergänzt die klassischen Ratschläge zum Thema Phishing, statt sie zu ersetzen. Die Adresse zu prüfen schützt dich vor gefälschten Seiten; die Anfrage zu lesen schützt dich vor echten Seiten, die kompromittiert wurden.

Wo SSP hilft

Wenn eine über WalletConnect verbundene dApp SSP um eine Signatur bittet, zeigt die Anfrage, welche Seite fragt, das Netzwerk und die Adresse, und SSP dekodiert gängige Aufrufe, bevor du zustimmst: Überweisungen, Freigaben und NFT-Anfragen „Freigabe für alle“ werden gekennzeichnet, bei den riskanteren mit ausdrücklichen Warnungen. Nachrichten werden nach Möglichkeit als lesbarer Text angezeigt, die Rohdaten stehen zur Prüfung bereit.

Anschließend braucht jede Anfrage eine zweite Bestätigung auf SSP Key, auf einem separaten Gerät. Das hindert eine gekaperte Website nicht daran, etwas Bösartiges anzufordern – aber es gibt dir zwei klare Gelegenheiten, die Anfrage als das zu erkennen, was sie ist, und keine davon auf der Seite, die der Angreifer kontrolliert.

Für Teams ergänzen SSP Enterprise Vaults Transaktionssimulation und Risikowarnungen, bevor Unterzeichner zustimmen. So erhält ein Vorschlag, der über ein kompromittiertes Front-End erstellt wurde, einen zweiten, unabhängigen Blick von allen, die ihn signieren müssen.

Das ehrliche Fazit

Ein Front-End-Hijack macht eine vertrauenswürdige Website zum Werkzeug des Angreifers, ohne die Contracts oder die URL anzurühren. Mit einem Blick in die Adressleiste erkennst du ihn nicht.

Was du tun kannst: Behandle jede Signaturanfrage als die eigentliche Oberfläche. Lies sie in deiner Wallet, prüfe Spender, Betrag und Empfänger, und lehne alles ab, was nicht zu dem passt, was du vorhattest.