Web3-Angriffsflächen: Ein Überblick zu Penetrationstests

Die ersten drei Artikel dieser Serie haben dargelegt, warum Krypto-Institutionen Blockchain-Penetrationstests benötigen (Teil 1), was diese Disziplin überprüft (Teil 2), und wie ein institutioneller Auftrag sicher vorbereitet und durchgeführt werden kann (Teil 3).

Dieser Artikel bietet einen Überblick über die für Penetrationstests einer Web3-Institution relevanten Angriffsflächen, mit besonderem Augenmerk darauf, wie die erforderliche Abdeckung über traditionelle Penetrationstest-Angriffsflächen hinausgeht [1]. Konkret wird zunächst ein Vier-Komponenten-Modell für Web3-Institutionen definiert, zusammen mit der Verantwortlichkeit, den Vertretern und den primären Angriffsflächen jeder Komponente. Aufbauend auf diesem Modell werden anschließend fünf Angriffsflächenbereiche untersucht, die geerbte Anwendungs- und Infrastrukturrisiken mit Web3-spezifischen Prüfpunkten bei Signierabsicht, Genehmigungs- und Signierabläufen, Fondslogik und On-Chain-Laufzeitverhalten verbinden.

Die Komponenten von Web3-Institutionen

Web3-Institutionen, darunter zentralisierte Börsen, Zahlungsdienstleister und DeFi-Projekte, verbinden konventionelle Anwendungs- und Infrastrukturumgebungen mit einer Off-Chain-zu-On-Chain-Geldverarbeitungskette [2]. Sie behalten traditionelle Penetrationstest-Angriffsflächen bei, führen jedoch zusätzliche Prüfpunkte rund um Transaktionsabsicht, Signierbefugnis, Fondsbuchhaltung und On-Chain-Ausführung ein. Um zu erkennen, wie diese Angriffsflächen zusammenwirken und welche Bedingungen einen Pfad zu Wertverlust bilden können, ist spezialisiertes Web3-Sicherheitsurteilsvermögen erforderlich.

Um diese erweiterte Angriffsfläche systematisch zu untersuchen, definiert dieser Abschnitt ein Vier-Komponenten-Modell: Application, Authorization and Signing, Blockchain Interaction und Infrastructure. Für jede Komponente wird deren Verantwortlichkeit beschrieben, werden repräsentative Implementierungen identifiziert und die primären Angriffsflächen zusammengefasst. Beachten Sie, dass unterschiedliche Web3-Institutionen diese Komponenten auf unterschiedliche Weise kombinieren oder auslagern können.

Komponente 1: Application

Die Komponente Application verarbeitet Anfragen von Nutzern oder internen Betreibern gemäß definierter Geschäfts- und Autorisierungslogik und übersetzt autorisierte Absicht in die vorgesehene Geschäftsaktion, etwa eine Vermögensübertragung oder einen Wiederherstellungsvorgang. Gängige Vertreter in Web3-Institutionen sind Web- und mobile Anwendungen, Browser-Erweiterungen und Backend-APIs.

Gängige Testarten.

• Web Application Penetration Testing

• Mobile Application Penetration Testing

• Browser Extension Penetration Testing

• API Penetration Testing

Die Komponente Application erbt traditionelle Angriffsflächen wie Identitäts- und Sitzungsverwaltung, Autorisierung und Isolation sowie Geschäftsablauf- und Zustandsübergangsintegrität. In einer Web3-Institution kann die in dieser Phase vorbereitete Geschäftsaktion oder Transaktionsabsicht anschließend durch die Komponente Authorization and Signing autorisiert und durch die Komponente Blockchain Interaction ausgeführt werden. Fehler in diesen Kontrollen können daher den Dienst unterbrechen oder sich zu direktem Vermögensverlust fortpflanzen.

Komponente 2: Authorization and Signing

Die Komponente Authorization and Signing empfängt Transaktionsanfragen, die von der Komponente Application vorbereitet wurden, und erzeugt die für die On-Chain-Übermittlung erforderlichen kryptografischen Signaturen. Einige Implementierungen können zusätzlich Richtlinien- oder Genehmigungsprüfungen innerhalb des Signiersystems durchführen, bevor eine Signatur erzeugt wird. Gängige Vertreter in Web3-Institutionen sind Wallet- und Signiersysteme oder -dienste.

Gängige Testarten.

• Identity and Privileged Access Testing

• Signing and Approval Workflow Testing

Zu den traditionellen Angriffsflächen, die von der Komponente Authorization and Signing geerbt werden, gehören privilegierte Identitäts- und Zugriffsverwaltung, API-Autorisierung und Aufgabentrennung sowie Integrität von Genehmigungs-, Wiederherstellungs- und Verwaltungsabläufen. In Web3-Institutionen können Fehler in dieser Komponente besonders schwerwiegende Folgen haben, da eine gültige Signatur direkt eine unumkehrbare Zustandsänderung oder Vermögensübertragung autorisieren kann. Als letzter kryptografischer Autorisierungsschritt vor der On-Chain-Übermittlung sollte die Komponente Authorization and Signing überall dort, wo sie eingesetzt wird, als kritische Sicherheitspriorität behandelt werden.

Komponente 3: Blockchain Interaction

Die Komponente Blockchain Interaction übermittelt Transaktionen, die von Nutzern oder internen Betreibern autorisiert wurden, bestätigt deren Ausführungsstatus und verfolgt den resultierenden On-Chain-Zustand. Gängige Vertreter in Web3-Institutionen sind Node- oder RPC-Gateways, Indexer und Relayer.

Gängige Testarten.

• API and RPC Penetration Testing

• Transaction-Submission and Relayer Abuse Testing

Obwohl Blockchain Interaction eine für Web3-Operationen spezifische Rolle erfüllt, konzentriert sich das Penetrationstesting dieser Komponente auf die feindliche Ausnutzbarkeit ihrer geerbten Angriffsflächen: Dienstanmeldedaten und Endpunktsicherheit, RPC- und API-Autorisierung sowie Integrität der Nachrichten- und Ereignisverarbeitung — zum Beispiel, ob RPC- oder Relayer-Verhalten missbraucht, die Transaktionsübermittlung manipuliert oder Chain-Ereignisse falsch interpretiert werden können. Für Institutionen, die angepasste oder selbst gehostete Blockchain-Nodes betreiben, sind Node- und Cluster-Korrektheit sowie großmaßstäbliche RPC-Resilienz — Synchronisation, Transaktionsverbreitung, Failover und Verfügbarkeit — ergänzende Aspekte, die durch Blockchain Security Testing und nicht durch Penetrationstests abgedeckt werden [2].

Komponente 4: Infrastructure

Die Komponente Infrastructure umfasst institutionsspezifische Infrastruktur- und Betriebssysteme, die die anderen drei Komponenten unterstützen oder beeinflussen. Gängige Vertreter in Web3-Institutionen sind Cloud-Plattformen, Netzwerkinfrastruktur, IAM- und Geheimnisverwaltungssysteme, Versionskontroll- und CI/CD-Systeme sowie Überwachungsplattformen.

Gängige Testarten.

• External and Internal Network Penetration Testing

• Cloud Infrastructure Penetration Testing

• CI/CD and Software Supply Chain Testing

Infrastructure erbt vor allem traditionelle Angriffsflächen, darunter Netzwerk- und Dienstexposition, Identitäts-, Privilegien- und Geheimnisverwaltung sowie Integrität der Softwarebereitstellung und Lieferkette. Obwohl Infrastructure typischerweise keine geldverarbeitenden Aktionen direkt ausführt, kann ihr Ausfall oder ihre Kompromittierung zu erheblichem Vermögensverlust führen. Die in Teil 1 besprochenen Vorfälle bei Bybit und TrustWallet veranschaulichen, wie Kompromittierungen bei Softwarebereitstellungs- und Verteilungskanälen sich bis in die Geldverarbeitungskette fortpflanzen können [1].

Web3-Angriffsflächen

Das Vier-Komponenten-Modell zeigt, dass Penetrationstests von Web3-Institutionen einen Großteil der traditionellen Anwendungs- und Infrastruktur-Angriffsfläche beibehalten. Der Unterschied liegt im geldverarbeitenden Kontext: Schwachstellen können sich über Komponenten hinweg fortpflanzen und Transaktionsabsicht, Signierung, Fondszustand oder On-Chain-Ausführung beeinträchtigen. Das Erkennen dieser Pfade und die Auswahl geeigneter Prüfpunkte erfordern daher spezialisiertes Web3-Sicherheitsurteilsvermögen.

Um diese Abdeckung zu strukturieren, gliedert dieser Abschnitt die Web3-Angriffsflächen in fünf Hauptangriffsflächenbereiche, die sich aus der in Teil 2 vorgestellten Geldverarbeitungskette und dem Testumfang ableiten [2]:

• Produktionsumgebung und automatisierte Betriebsabläufe

• Web- und dApp-Frontends, Autorisierung und Signierabsicht

• Signier-, Genehmigungs- und Auszahlungsautorisierungsketten

• Fonds-Geschäftslogik

• On-Chain-Transaktionen und bereitgestellte Contracts

Produktionsumgebung und automatisierte Betriebsabläufe

Die Produktionsumgebung unterstützt jede Phase der Geldverarbeitungskette. Ein herkömmlicher Infrastruktur-, Identitäts- oder Softwarebereitstellungs-Fußabdruck bewegt möglicherweise keine Gelder direkt, kann jedoch das Verhalten von Application verändern, Authorization and Signing erreichen oder Blockchain Interaction beeinflussen. Blockchain-Penetrationstests bewerten daher die erreichbare Auswirkung des Fußabdrucks auf die Geldverarbeitungskette, anstatt den Infrastrukturbefund als isolierten Endpunkt zu behandeln [2].

Testschwerpunkt. Tester prüfen, ob Zugriff, Bereitstellung, Geheimnisse oder Betriebskontrollen zu einer geldverarbeitenden Aktion verkettet werden können. Ein Szenario kann mit einem exponierten Dienst, einer kompromittierten Identität, Workload-Anmeldedaten, einem Build-Token, einer Abhängigkeit oder einer Anbieterintegration beginnen und dann bewerten, ob IAM, Segmentierung, Geheimnisverwaltung, Änderungskontrolle und Dienstautorisierung eine weitere Ausbreitung verhindern. Die daraus resultierenden Nachweise sollten den operativen Fußabdruck mit den Komponenten und wertbewegenden Aktionen verknüpfen, die er beeinflussen kann.

Die detaillierte Analyse [3] untersucht, wie sich die Kompromittierung der Produktionsumgebung durch Bereitstellungs- und Betriebskontrollen bis in geldverarbeitende Komponenten fortpflanzen kann.

Web- und dApp-Frontends, Autorisierung und Signierabsicht

Web- und dApp-Frontends sind die primäre Interaktionsschicht, über die Nutzer und Betreiber geldverarbeitende Aktionen initiieren und überprüfen und an den Autorisierungs- und Signierabläufen teilnehmen, durch die diese Aktionen genehmigt werden. Diese Position macht sie zu attraktiven Zielen für Phishing und Frontend-Hijacking, da die Kontrolle über die Oberfläche den Kontext oder Inhalt einer Transaktionsanfrage manipulieren kann, bevor sie ein Wallet oder Signiersystem erreicht [1].

Testschwerpunkt. Tester prüfen, ob die einem Nutzer oder Betreiber präsentierte Transaktion von der letztlich autorisierten Aktion abweichen kann. Die Bewertung verfolgt die Anfrage von der Anwendungsauthentifizierung und -autorisierung über die Transaktionskonstruktion, Wallet-Darstellung, Signatur und Übermittlung und berücksichtigt dabei, ob Sitzungszustand, Wallet-Berechtigungen, Simulation, Chain-Kontext, Contract-Kontext oder Anzeigelogik die Bedeutung verändern können. Die Nachweise sollten die präsentierte Aktion, den tatsächlichen Payload, die resultierende Signatur und das übermittelte Verhalten bewahren.

Die detaillierte Analyse [4] verfolgt die Transaktionsabsicht von der Anwendungsdarstellung über die Wallet-Autorisierung bis zum signierten oder übermittelten Ergebnis und konzentriert sich darauf, wo die Bedeutung der Aktion abweichen kann.

Signier-, Genehmigungs- und Auszahlungsautorisierungsketten

Signierung ist oft eine geldbewegende Aktion, aber kryptografische Gültigkeit allein begründet noch keine korrekte Geschäftsbefugnis. Das Sicherheitsergebnis hängt zudem davon ab, wer die Anfrage initiiert hat, welche Richtlinie angewendet wurde, was die Genehmiger überprüft haben und ob der Payload unverändert geblieben ist. Eine Schwachstelle in dieser Kontrollkette kann dazu führen, dass ein legitimer Signierer eine unbeabsichtigte Aktion autorisiert [2].

Testschwerpunkt. Tester prüfen, ob Identitäten, Rollen, Richtlinienprüfungen oder Genehmigungsschritte umgangen oder kombiniert werden können. Szenarien können bewerten, ob eine einzelne Identität eine Aktion initiieren und genehmigen kann, ob eine Änderung des Ziels oder Limits ohne unabhängige Überprüfung wirksam wird, ob die Richtlinie beim Signierer oder nur in einer Oberfläche durchgesetzt wird, oder ob sich ein Payload nach der Genehmigung ändern kann. Die Nachweise sollten die getestete Abfolge, die durchbrochenen Kontrollen und die ermöglichte unautorisierte Aktion dokumentieren.

Die detaillierte Analyse [5] untersucht, ob institutionelle Genehmigungs- und Signierabläufe die Geschäftsbefugnis von der Transaktionsinitiierung über die Signierung bis zur Auszahlungsausführung bewahren.

Fonds-Geschäftslogik

Verwahrende Institutionen verlassen sich auf Off-Chain-Zustände, um Salden, Verpflichtungen und die Freigabefähigkeit von Werten zu bestimmen. Eine unbeabsichtigte Gutschrift oder Zustandsänderung kann daher zu einem direkten finanziellen Verlust werden, selbst wenn kein Signierschlüssel oder Smart Contract kompromittiert wurde. Beim Testen müssen die wirtschaftliche Invariante und der Abstimmungspfad berücksichtigt werden, nicht nur, ob eine einzelne API wie implementiert funktioniert [2].

Testschwerpunkt. Tester prüfen, ob Salden, Limits, Abstimmung, Auszahlungsregeln oder Zustandsübergänge unbeabsichtigte Bedingungen akzeptieren. Szenarien können untersuchen, ob eine Einzahlung ohne den erwarteten Wert gutgeschrieben wird, ob ein Ereignis mehrere Gutschriften erzeugt, ob Präzision oder Nebenläufigkeit einen Saldo verändert, oder ob ein ungültiger Zustand auszahlbar wird. Die Nachweise sollten die resultierenden Zustandsübergänge und einen reproduzierbaren Pfad geschäftlicher Auswirkungen erfassen, nicht nur einen technischen Fehler.

Die detaillierte Analyse [6] untersucht, wie unbeabsichtigter Off-Chain-Fondszustand über institutionelle Arbeitsabläufe hinweg erzeugt, fortgepflanzt und in auszahlbaren Wert umgewandelt werden kann.

On-Chain-Transaktionen und bereitgestellte Contracts

Die On-Chain-Übergabe ist der Punkt, an dem Off-Chain-Absicht zu öffentlichem Laufzeitverhalten wird. Transaktionen können unumkehrbar sein, und bereitgestellte Contracts sind öffentlich aufrufbar und mit Systemen außerhalb der direkten Kontrolle der Institution kombinierbar. Die Bewertung muss daher die Beziehung zwischen der beabsichtigten Aktion, der übermittelten Transaktion, der beobachteten Ausführung und dem von der Institution interpretierten Zustand bewahren [2].

Testschwerpunkt. Tester prüfen, wie sich die On-Chain-Interaktionen der Institution unter feindlichen Laufzeitbedingungen verhalten. Szenarien können untersuchen, ob Transaktionsfelder sich über Konstruktion, Signierung und Übermittlung hinweg ändern können. Sie können auch bewerten, ob RPC- oder Relayer-Verhalten die Aktion beeinflusst, ob Chain-Ereignisse korrekt interpretiert werden, und ob bereitgestellte Berechtigungen, Upgrades oder Protokollkomposition das erwartete Ergebnis verändern. Die Nachweise sollten die übermittelte Transaktion, den relevanten Chain-Kontext und das beobachtete Laufzeitergebnis bewahren.

Für diesen Bereich bleibt das Penetrationstesting auf feindliche Laufzeitinteraktion und Nachweise auf Transaktionsebene fokussiert. Die Codeebenen-Sicherung von Contracts verbleibt im Rahmen von Code Audit, während Node- oder Cluster-Korrektheit sowie großmaßstäbliche RPC-Resilienz im Rahmen von Blockchain Security Testing verbleiben [2].

Fazit

Blockchain-Penetrationstests behalten die traditionellen Anwendungs- und Infrastruktur-Angriffsflächen bei, die in konventionellen Bewertungen untersucht werden. Was sie auszeichnet, ist die Notwendigkeit, Schwachstellen über diese Einstiegspunkte hinaus durch die Geldverarbeitungskette der Institution zu verfolgen, wo Fehler bei der Anfrageverarbeitung, Autorisierung, Softwarebereitstellung oder Infrastruktur die kryptografische Signierung, den Fondszustand oder die On-Chain-Ausführung beeinträchtigen können.

Um diese Zusammenhänge explizit zu machen, verwendet dieser Artikel ein Vier-Komponenten-Modell: Application bereitet Geschäftsaktionen vor, Authorization and Signing erzeugt Signaturen, Blockchain Interaction übermittelt Transaktionen und interpretiert Ergebnisse, und Infrastructure unterstützt oder beeinflusst die anderen Komponenten. Zusätzlich zeigen fünf Angriffsflächenbereiche auf, wo spezialisiertes Web3-Sicherheitsurteilsvermögen am wichtigsten ist, insbesondere an den Grenzen zwischen Transaktionsabsicht, Signierbefugnis, Fondslogik und On-Chain-Laufzeitverhalten.

Vier weiterführende Leitfäden erweitern diesen Überblick um eigene Analysen zu Anwendungsautorisierung und Signierabsicht, Cloud- und CI/CD-Sicherheit, Treasury-Kontrolle und Börsen-Ledger-Logik. On-Chain-Transaktionen und bereitgestellte Contracts bleiben in diesem Überblick abgedeckt.

BlockSec hilft Institutionen, das Vier-Komponenten-Modell und die fünf Angriffsflächenbereiche in einen testbaren Umfang zu überführen, indem Komponenten, Verantwortliche, Geldflüsse und Vertrauensgrenzen kartiert, Angreiferperspektiven ausgewählt, sichere Nachweisverfahren definiert und die relevanten potenziellen Pfade validiert werden. Um die Angriffsfläche für Ihren nächsten Auftrag zu bestimmen, fordern Sie ein Scoping-Gespräch an. Weitere Informationen sind auf Anfrage erhältlich.

Ebenfalls in dieser Serie, demnächst erscheinend:

• Teil 5: Authorization and Signing Security: Web, dApps, und
• Teil 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Teil 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Teil 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

Die Blockchain Penetration Testing pillar page bietet die Sicht auf Auftragsebene.

Referenzen

Nummeriert in der Reihenfolge des ersten Auftretens.

1. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
2. BlockSec, What Is Blockchain Penetration Testing? Definitions and Boundaries.
3. BlockSec, erscheint demnächst.
4. BlockSec, erscheint demnächst.
5. BlockSec, erscheint demnächst.
6. BlockSec, erscheint demnächst.