DApps - Dezentrale Anwendungen

Reading time: 5 minutes

{{#include ../../banners/hacktricks-training.md}}

Was ist eine DApp?

Eine DApp ist eine dezentrale Anwendung, die in einem Peer-to-Peer-Netzwerk läuft, anstatt auf einem zentralen Server gehostet zu werden. DApps basieren typischerweise auf Blockchain-Technologie, die Transparenz, Sicherheit und Unveränderlichkeit von Daten ermöglichen sollte.

Web3 DApp Architektur

Laut diesem Beitrag gibt es 3 verschiedene Arten von Web3 DApp-Architekturen:

"API-losen" DApps

Diese DApps sind auf einer Blockchain aufgebaut und verlassen sich nicht auf zentrale APIs oder Backends. Man könnte denken, dass die Blockchain das tatsächliche Backend der Anwendung ist. Sie sind vollständig dezentralisiert und können direkt über die Blockchain aufgerufen werden.

Um mit der Blockchain zu interagieren, verwendet der Client normalerweise eine Wallet. Die Wallet signiert die Transaktionen und sendet sie an die Blockchain. Der Client kann auch einen Node verwenden, um Daten von der Blockchain zu lesen.

"API-aktivierten" DApps

Diese DApps sind auf einer Blockchain aufgebaut, verlassen sich jedoch auch auf zentrale APIs, um Informationen zu sammeln. Sie sind größtenteils dezentralisiert, da die Kernfunktionalität der DApp trotz der Abhängigkeit von einer zentralen API weiterhin auf der Blockchain liegt. Die Kommunikation des Clients mit der Blockchain erfolgt normalerweise über eine Wallet.

Ein gutes Beispiel für diese Art von DApp ist eine NFT-Minting-Anwendung. Der Server ermöglicht das Hochladen der Bilder, aber das Minting erfolgt durch den Client über eine Wallet.

"Vollständige" DApps

Diese DApps sind auf einer Blockchain aufgebaut, verlassen sich jedoch auch auf zentrale APIs und Backend-Server. Sie könnten teilweise dezentralisiert sein, da der Client möglicherweise in der Lage ist, Operationen auf der Blockchain über eine Wallet durchzuführen. In der Regel kann jedoch auch das Backend Operationen auf der Blockchain durchführen.

Ein gutes Beispiel für diese Art von DApp ist eine Cross-Chain-Brücke, bei der eine Offchain-Komponente benötigt wird, um mit beiden Smart Contracts in verschiedenen Blockchains zu kommunizieren, um den Transfer von Vermögenswerten durchzuführen.

Web2-Sicherheitsanfälligkeiten

Web2-Sicherheitsanfälligkeiten betreffen weiterhin diese Art von Anwendungen, obwohl ihre Auswirkungen variieren können:

  • Client-seitige Sicherheitsanfälligkeiten haben eine erhöhte Auswirkung, da der Client in den Web3 DApps normalerweise derjenige ist, der Operationen auf der Blockchain über eine Wallet durchführt. Das bedeutet, dass Angriffe wie XSS, die es schaffen, JS-Code auf der Client-Seite auszuführen oder den Inhalt der Seite zu manipulieren, größere Auswirkungen haben können, da sie mit der Wallet interagieren und den Benutzer überzeugen können, unerwünschte Operationen auf der Blockchain durchzuführen.
  • Beachten Sie, dass der Client in diesen Arten von Anwendungen normalerweise die Operationen überprüfen kann, bevor er sie mit der Wallet signiert. Wenn der Angreifer jedoch in der Lage ist, den Inhalt der Seite zu manipulieren, kann er den Benutzer überzeugen, eine Transaktion zu signieren, die eine unerwünschte Operation auf der Blockchain ausführt.
  • Server-seitige Sicherheitsanfälligkeiten sind weiterhin in den DApps vorhanden, die auf einen Backend-Server angewiesen sind. Die Auswirkungen dieser Sicherheitsanfälligkeiten hängen von der Architektur der DApp ab. Sie könnten jedoch weiterhin sehr problematisch sein, da ein Angreifer im Backend Schlüssel des Unternehmens finden könnte, um auf die Mittel der Smart Contracts zuzugreifen, oder eine Kontoübernahme durchführen könnte, die es ihm ermöglicht, Gelder oder NFTs von den Benutzern zu stehlen.

Natürlich wird die Angriffsfläche der DApp reduziert, wenn die DApp kein Backend verwendet oder das verwendete Backend nur öffentliche Kettendaten oder statische Seiten anbietet.

Web3 Angriffsfläche

Obwohl eine DApp im Allgemeinen eine reduzierte Angriffsfläche hat, da mehrere Sicherheitsprüfungen immer auf der Blockchain durchgeführt werden, gibt es dennoch einige Angriffsvektoren, die von einem Angreifer ausgenutzt werden können.

Es könnte möglich sein, die Sicherheitsanfälligkeiten von Web3 DApps in die folgenden Kategorien zu gruppieren:

  • Fehlerhaft behandelte On-Chain-Transaktionen: falsch formatierte oder uneingeschränkte Transaktions-APIs, fehlende Logik für das Warten auf Antworten und Blockbestätigungen, Offenlegung sensibler Daten und unsachgemäße Behandlung fehlgeschlagener, zurückgesetzter oder intern typisierter Transaktionen, die böswillige Calldata-Injektionen ermöglichen.

  • Smart-Contract-gesteuerte Backend-Angriffe: Speichern oder Synchronisieren sensibler Daten zwischen Verträgen und Datenbanken ohne Validierung, nicht überprüfte Ereignisemissionen oder Vertragsadressen und ausnutzbare Vertragsanfälligkeiten, die die Backend-Logik vergiften können.

  • Fehlerhafte Krypto-Asset-Operationen: falsche Verarbeitung verschiedener Token-Typen (native vs. ERC-20), Ignorieren der Dezimalgenauigkeit, fehlgeschlagene Überweisungen oder interne Transaktionen und Akzeptieren gefälschter, deflationärer, Rebase- oder slippageanfälliger Token ohne Validierung, was Payload-Injektionen über Token-Metadaten ermöglicht.

Einige Beispiele aus diesem Beitrag:

Gelder verschwenden: Backend zwingen, Transaktionen durchzuführen

Im Szenario Wasted Crypto in Gas via Unrestricted API kann der Angreifer das Backend zwingen, Funktionen eines Smart Contracts aufzurufen, die Gas verbrauchen. Der Angreifer, der nur eine ETH-Kontonummer sendet und keine Limits hat, zwingt das Backend, den Smart Contract zu registrieren, was Gas verbraucht.

DoS: Schlechte Transaktionsbearbeitungszeit

Im Szenario Poor Transaction Time Handling Leads to DoS wird erklärt, dass das Backend die HTTP-Anfrage offen hält, bis eine Transaktion durchgeführt wird. Ein Benutzer kann daher leicht mehrere HTTP-Anfragen an das Backend senden, was alle Ressourcen des Backends verbraucht und zu einem DoS führt.

Backend<-->Blockchain Desynchronisation - Race Condition

Im Szenario Poor Transaction Time Handling Leads to Race Condition wird erklärt, dass es in einem Spiel möglich war, dass der Benutzer eine Abhebungsanfrage an das Backend sendete, das dem Benutzer seine Münzen sendete. Während die Transaktion noch bearbeitet wurde, konnte der Benutzer diese Münzen verwenden, um Artikel im Spiel zu kaufen und sie kostenlos zu erhalten.

Ein weiteres Beispiel könnte sein, dass der Benutzer in der Lage ist, dieselben Münzen zu verwenden, um verschiedene Artikel zu kaufen, da das Backend den Artikel sofort an den Benutzer gibt, ohne auf die Bestätigung der Transaktion zu warten und daher nicht auf den Benutzerstand in der Blockchain zu warten.

Validierung der Smart Contract-Adresse

Im Szenario Bridge Backend Lacks Smart Contract Address Validation wird erklärt, wie das Backend die Adresse des Smart Contracts überprüfte, sodass es einem Angreifer möglich war, einen gefälschten Smart Contract bereitzustellen, Gelder darauf zu legen, die Transaktion an das Backend zu senden und das Backend denken ließ, dass der Benutzer Gelder an den echten Smart Contract gesendet hatte, wodurch der Benutzer die Token erhielt.

Fehlbehandlung von Vermögenswertklassen

Im Szenario Mishandling of Asset Classes wird erklärt, dass das Backend ein betrügerisches NFT in einer Adresse mit 1 MATIC verwechselte, wodurch es dem Angreifer ermöglicht wurde, Hunderte von betrügerischen NFTs an die Adresse zu senden und dafür jeweils 1 MATIC von der Plattform zu erhalten.

Referenzen

{{#include ../../banners/hacktricks-training.md}}