Web3 Anwendungs-Penetrationstests: Leitfaden für dApps, Wallets und APIs

Kurzfassung: Dieser Leitfaden zeigt, wie Sicherheitstests für Web3-Stacks 2025 konkret geplant, ausgeführt und gemessen werden – mit fokussierten Checklisten für Smart Contracts, Wallets (EOA, AA/4337, EIP‑7702) und APIs. Enthält aktuelle Bedrohungsdaten, Tooling-Playbooks (Foundry/Slither/Echidna/Certora), Frontend‑Supply‑Chain‑Härtung, MEV‑Schutz und praxisnahe Testfälle.

Warum jetzt (2024–2025 in Zahlen)

2024 wurden rund 2,2 Mrd. USD durch Krypto‑Hacks gestohlen; 2025 war bereits zur Jahresmitte schlimmer als 2024, getrieben u. a. vom Bybit‑Vorfall (~1,5 Mrd. USD, von der US‑Bundespolizei DPRK zugeschrieben). Decision‑Maker müssen Security-by-Design budgetieren – nicht reaktiv. (chainalysis.com)
Infrastruktur‑Angriffe (Schlüssel/Seed‑Kompromittierung) machten 2024 den Großteil der Verluste aus; DeFi bleibt bevorzugtes Ziel. 2025 verschiebt sich der Schwerpunkt zusätzlich zu Wallet‑Phishing und neuen Delegations-/Signaturmustern. (trmlabs.com)
L2‑Sicherheits‑/Governance‑Realität: Im Juni 2024 stoppte ConsenSys’ zkEVM Linea kurzfristig die Blockproduktion (Sequencer‑Pause) und zensierte Angreifer‑Adressen, um Brückenabflüsse nach einem DEX‑Exploit zu begrenzen – ein Lehrbuchfall für Notfall‑Kontrollen und Zentralisierungsrisiko. (unchainedcrypto.com)

Dieser Leitfaden übersetzt diese Lage in ein überprüfbares Test‑Vorgehen für dApps, Wallets und APIs.

Test‑Rahmenwerk von 7Block Labs

Wir strukturieren Projekte in drei Phasen mit klaren Artefakten.

Vorbereitungsphase (1–2 Wochen)

Bedrohungsmodell pro Domäne:
- dApp/Protokoll: Vermögensfluss, Rollen/Privilegien, Upgrades/Proxies, Orakel/Brücken, L2‑Abhängigkeiten.
- Wallets: Signaturen, Delegation (EIP‑7702), AA‑Pfade (ERC‑4337), Frontend‑Supply‑Chain.
- APIs/Backends: AuthN/AuthZ, Webhook‑Flows, SSRF/OOB‑Kanäle, Raten‑Limiting.
Sicherheits‑SLOs: maximale ausnutzbare TVL‑Quote, MTTD/MTTR, erlaubte Pausen/Freezes (Runbooks).
Tooling‑Plan: Slither (Static), Foundry (Fuzz+Invarianten), Echidna (Properties), Certora (formale Regeln), Forta‑Bots (Rund‑um‑die‑Uhr‑Monitoring). (github.com)

Ausführung (2–4 Wochen)

Tiefen‑Tests pro Schicht (siehe Checklisten unten), reproduzierbare Angriffspfade, Code‑Fix‑PRs, formale Spezifikationen/Regeln und Fuzz‑Korpora, Notfall‑Prozeduren.

Härtung & Betrieb

„Guardrail“-Deploys (Pausen/Freezes, Notfall‑Rollen), private Mempools (MEV‑Schutz), Forta‑Alarmierung, Bug‑Bounties, Regression‑Suiten in CI. (docs.flashbots.net)

A. dApps/Smart‑Contracts: präzise Test‑Checkliste

1) Statische Analyse & Architektur

Slither mit Upgrade‑Prüfern:
- Speicherlayout & Proxies (Transparent, UUPS),
```
delegatecall
```
  -Pfade, EIP‑1967‑Slots; „slither-check-upgradeability“. Ergebnisse als SARIF in CI. (github.com)
Projektweite Anti‑Pattern:
- ungeschützte
```
initialize
```
  /Re‑Initialisierung (Upgrades), schwache Zugriffskontrolle, unsichere
```
permit
```
  /EIP‑2612‑Implementierungen (Nonces/Deadline/Domänentrennung). (eips.ethereum.org)

Praktischer Befehl

# Static review + ERC-Konformität + Upgradeability
slither . --checklist --solc-remaps "@openzeppelin=node_modules/@openzeppelin" \
  --print contract-summary --print human-summary \
  --detect reentrancy-unlimited-gas,uninitialized,low-level-calls \
  --json slither-report.json

2) Fuzzing & Invarianten (Foundry/Echidna)

Foundry Invariants: Zustandsinvarianten (z. B. Gesamtsumme aller Guthaben == totalSupply; Uniswap‑x*y=k), Handler‑basiert, Coverage‑guided Fuzzing (ab v1.3.0) mit persistentem Korpus. (getfoundry.sh)
Echidna Properties: standardisierte 168+ wiederverwendbare Eigenschaften (ERC‑Konformität, Fixed‑Point‑Math), ergänzt um projektspezifische Regeln. (blog.trailofbits.com)

Beispiel: Foundry‑Konfiguration (Auszug)

# foundry.toml
[fuzz] runs = 20000
[invariant]
depth = 32
fail_on_revert = false
corpus_dir = "invariant_corpus"

(getfoundry.sh)

3) Formale Verifikation (gezielt)

Certora Prover: High‑Level‑Eigenschaften (z. B. „Nach jedem Upgrade bleibt Storage‑Mapping bis Slot N unverändert“, „Allowance nimmt bei transferFrom deterministisch ab“, „kein Wertverlust über Liquidationspfade“). Ergebnisse in CI pro Commit. (docs.certora.com)

4) Upgrades & Admin‑Kontrollen

Proxy‑Practice: Änderungen am Storage nur ans Ende anhängen, Konstruktoren durch Initializer ersetzen; Layout‑Checks via OpenZeppelin Plugins (Hardhat/Foundry). Mehrfach‑Signaturen für Upgrades. (docs.openzeppelin.com)
„Guardian“-Muster aus DeFi: Notfall‑Freeze/Pause über dedizierte Rollen (z. B. Aave EMERGENCY_ADMIN / FreezingSteward) plus gestufte Governance‑Prozesse (Snapshot→On‑Chain). Planen Sie diese Mechanismen bei Protokoll‑Design und Runbooks ein. (governance-v2.aave.com)

5) L2‑, Brücken‑, Orakel‑Risiken

L2‑Sequencer‑Kontrollen: Testen, ob Protokoll bei Sequencer‑Pause/Delay ausfallsicher ist und „censorship“-Szenarien toleriert (Time‑outs, Resubmit, Rate‑Limits). Der Linea‑Vorfall ist Referenzfall. (unchainedcrypto.com)
Brücken‑Governance: Schlüssel‑/MPC‑Risikoprüfung, Signer‑Schwellen, Alarmierung. Orbit‑Bridge zeigte 2024, wie Keys/Multisig‑Kompr. zu >80 Mio. USD Verlust führten. (blockworks.co)

B. Wallet‑Sicherheit: EOA, ERC‑4337 und EIP‑7702 richtig testen

1) Account Abstraction (ERC‑4337)

EntryPoint‑Versionierung prüfen: v0.7 gilt als aktuelle Linie; Adressen sind chain‑weit kanonisch (v0.7: 0x0000…da032, v0.6: 0x5FF1…2789). Testen Sie Kompatibilität (PackedUserOperation vs. UserOperation) und Migrationspfad von v0.6 → v0.7. (alchemy.com)
Bounty/Ökosystem‑Sicherheit: EF‑Bug‑Bounty für 4337/7562 (bis 250k USD) existiert – relevante Versionen 0.6/0.7/0.8. Halten Sie Bundler/Paymaster aktuell. (docs.erc4337.io)
Real‑World‑Befund: Fireblocks meldete 4337‑Modul‑Schwachstelle (UniPass) mit potenzieller Account‑Übernahme (Trusted‑EntryPoint‑Austausch). Stellen Sie sicher, dass EntryPoint‑Trust‑Annahmen fest verankert/blocked sind. (fireblocks.com)

Praktische Tests

UserOp‑Validierung: Signatur/Nonce‑Handling, Replay‑Resistenz;
```
validateUserOp
```
‑Gas‑Budget & Revert‑Gründe.
Paymaster‑Missbrauch: Sponsor‑Policy, Domain‑Trennung, Missbrauch durch „Gasless“‑Flows; Cross‑Chain‑Wiederholung.
Negative Tests: Malformed calldata/UserOp‑Hash‑Divergenz. (medium.com)

2) EIP‑7702 (EOA‑Delegations‑Transaktionen)

7702 erlaubt es EOA‑Konten, Code zu setzen (TX‑Typ 0x04) und vorübergehend wie Contract‑Accounts zu agieren; die Spezifikation warnt ausdrücklich, dass Wallets keine generische UI anbieten sollen, um „Autorisierungen“ blind signieren zu lassen. Testfall: UI blockiert solche Aufforderungen oder zeigt rote Warnungen. (eips.ethereum.org)
Prüfungen: Delegations‑Ziele nur aus auditierter Allowlist; keine ungebundenen „Batch“‑Signaturen; Domain‑/Chain‑Binding strikt erzwingen.

3) Signaturen & Permit‑Flows

EIP‑712 (SignTypedData) & EIP‑1271 (Smart‑Contract‑Signaturen), EIP‑6492 (Predeploy‑Sig‑Validierung) – prüfen Sie Domain‑Separator, Nonces, Ketten‑IDs/Replay‑Schutz in dApp‑Flows (SIWE/Off‑Chain‑Auth). (eips.ethereum.org)
Uniswap Permit2: Zeitlich begrenzte, batch‑fähige Approvals; Pen‑Tests müssen gefakte „Witness“-Daten, Nonce‑Wiederverwendung und versehentliche globale Freigaben erkennen. Nutzer‑Aufklärung ist Pflicht – Uniswap warnt vor leicht zu missbrauchenden Signaturen. (github.com)

4) Phishing/Drainer & Address‑Poisoning

2024 stiegen Verluste durch „Wallet Drainers“ signifikant; ScamSniffer schätzt ~494 Mio. USD (332k Adressen). Testen Sie Anti‑Phishing‑UX (Simulation, Clear‑Signing‑Warnungen, Token‑Allowance‑Inspektion) und „Address Poisoning“‑Schutz (Adressbuch/Whitelist, Warnungen bei History‑Copy). (drops.scamsniffer.io)
„Address Poisoning“: Winzige Täuschungs‑Transfers erzeugen ähnlich aussehende Adressen in der Historie; mehrere Fälle mit sechs‑/siebenstelligen USD‑Verlusten dokumentiert. Wallets sollten vor Copy‑Vergleichen warnen, Checksummen / ENS / Adressbuch fördern. (cointelegraph.com)

5) Frontend‑/Supply‑Chain‑Härtung

Ledger‑Connect‑Kit‑Vorfall (Dez 2023) demonstriert NPM/CDN‑Supply‑Chain‑Risiken: Drainer‑Payload in Web3‑Connector injiziert. CI/CD‑Kontrollen: Lockfiles, 2‑Personen‑Freigabe, „pinned versions“, SRI‑Hashes, CSP Nonces/Hashes, Build‑Integrität. (ledger.com)
CSP/SRI Pflichtprogramm:
- CSP
```
script-src
```
  mit Nonces/Hashes;
```
unsafe-inline
```
  und
```
unsafe-eval
```
  vermeiden; Trusted Types bei Bedarf.
- SRI für externe Skripte/CSS; CORS‑Regeln beachten. Implementieren und im Security‑Header‑Scanner verifizieren. (developer.mozilla.org)

C. API‑/Backend‑Sicherheit für Web3

Mappen Sie Ihre Tests auf OWASP API Security Top 10 (2023). Besonders kritisch: BOLA/BFLA (API1/5), SSRF (API7), „Unsafe Consumption of APIs“ (API10) für Orakel/Webhooks/RPC‑Proxys. (owasp.org)
SIWE (EIP‑4361) richtig: Nonce/Domain‑Binding und Ablaufzeiten, ReCaps (EIP‑5573) für „scoped capabilities“ – d. h. „Sign‑In“ getrennt von granularer Autorisierung externer Dienste. (eips.ethereum.org)
JSON‑RPC‑Gateways:
- Ketten‑ID/Netzwerk strikt verifizieren, Nonce‑Management bei Reorgs, WebSocket‑Auth (Token/Origin), Rate‑Limits, Request‑Recording für Forensik.
- Webhook‑Signaturen & IP‑Allowlisting; SSRF/DNS‑Rebinding‑Schutz für Off‑Chain‑Resolver.

D. MEV‑/Mempool‑Risiko und praktische Schutzmaßnahmen

Private Orderflow / Schutz‑RPC:
- Flashbots Protect RPC und CoW Protocol „MEV Blocker“ leiten Transaktionen an private Mempools, verhindern Sandwiching/Fr frontrunning, bieten teils Refunds. Validieren Sie Latenz, Ausfall‑Fallback zum öffentlichen Mempool, Slippage‑Kontrollen bleiben Pflicht. (docs.flashbots.net)
Simulationen vor Broadcast:
- Vor dem Senden Transaktion gegen aktuelle Chain‑State simulieren (z. B. Blocknative Simulation Platform) und im dApp‑Flow anzeigen. Prüfen Sie Sim‑/Chain‑Abweichungen gezielt (Sandboxes in Tests). (blocknative.com)
Oracle Extractable Value (OEV): Orakel‑Updates via private Mempool einspeisen und OEV zurückerstatten – potenziell deutliche Reduktion „verlorener“ Wertschöpfung. (docs.cow.fi)

E. Praxis: drei konkrete Testfälle (mit Output‑Artefakten)

Unbefugter Wertabfluss in ERC‑4626‑Vault verhindern (Foundry‑Invarianten)

// Handler basierter Invariantentest (Auszug)
function invariant_TotalSupplyEqSumShares() public {
    assertEq(vault.totalSupply(), handler.sumOfShares());
}

function invariant_NoAssetLeak() public {
    assertGe(vault.totalAssets(), handler.sumOfDepositedAssets());
}

Ziel: Invarianten laufen mit depth≥32, runs≥20k; Korpus persistiert. Report: gas‑Stats, Korpus‑Mutationen, Reverts‑Quote. (getfoundry.sh)

Permit‑/Permit2‑Missbrauch

Falsch signierte „Witness“-Daten, überschießende Allowances, unverfallene Approvals. PoC: Simulation + „Revoke“‑Pfad + gebundene Zeitfenster; Nutzer‑Warn‑UX per Clear‑Signed 712. Artefakt: JSON von signTypedData, Test‑Decoder, Repro‑Skips. (github.com)

4337‑Paymaster‑Fehlkonfiguration

Tests auf Sponsorship‑Policy (Ziel‑Contracts/Methoden, Gas‑Obergrenzen), Replays versch. Chains. EntryPoint‑Adressvalidierung (v0.7). Artefakt: UserOp‑Sammlung + Negativ‑Fälle + Bundler‑Logs. (alchemy.com)

F. Monitoring, Notfall & Bounty

Forta‑Bots einsetzen (Attack Detector): Phasen Funding/Preparation/Exploitation/Laundering erkennen; Alerts in PagerDuty/Slack; Playbooks für Freeze/Blocklisten/Withdraw‑Pausing. (docs.forta.network)
Runbooks:
- Notfallrollen (Multisig) → Freeze/Parameter‑Senkung/Preis‑Kappen, Time‑Locks.
- Kommunikationsplan (On‑Chain‑Mitteilung, Forensik‑Adresse, Rückabwicklung).
Bounty‑Programme: Bei AA/4337 zusätzlich EF‑Bounty; projekt‑eigene Programme via Immunefi; Offenlegungspfad dokumentiert. (docs.erc4337.io)

G. Spezifische Wallet‑/Frontend‑Härtung in der Praxis

Frontend:
- CSP strikt (Nonces/Hashes, kein
```
unsafe-inline/eval
```
  ), SRI für externe Ressourcen, Abkehr von CDN‑Runtime‑Skripten wo möglich, 2‑Personen‑Freigaben für NPM/CI. (developer.mozilla.org)
Wallet‑UX:
- Deutliche Risikohinweise bei EIP‑7702‑Autorisationen; keine generische Delegations‑UI; Signatur‑Diff/Simulation anzeigen; Adressbuch & History‑Warnungen („nicht aus Historie kopieren“). (eips.ethereum.org)
Nutzer‑Schutz:
- Standardmäßig private RPCs vorschlagen, aber Slippage‑Kontrollen nicht lockern; „Revoke“‑Shortcuts; Aufklärung zu Drainer‑Signaturen & Address‑Poisoning (Meldung/Blocklist). (mevblocker.io)

H. Solana/Cosmos‑Programme: knappe, aber wichtige Unterschiede

Reentrancy klassisch kaum möglich (CPI‑Modell, Signer‑/Account‑Berechtigungen), doch Audit‑Fokus auf CPI‑Guard, Program‑Checks, Re‑Init‑/Account‑Reload‑Fehlern. Testen Sie:
- „Arbitrary CPI“ verhindern (Programm‑ID validieren),
- ```
is_initialized
```
  ‑Flags/Re‑Init,
- Nach CPIs Accounts reloaden (Anchor:
```
reload()
```
  ),
- Token‑2022
```
CpiGuardExtension
```
  nutzen. (solana.com)

I. Was Sie von einem 7Block‑Pentest erwarten

Technische Artefakte:
- Slither‑Berichte (SARIF/JSON), Foundry‑Invarianten + Korpus, Echidna‑Configs/Properties, Certora‑Spezifikationen.
- Exploit‑PoCs (lokal/fork), Fix‑PRs, Migrations‑/Upgrade‑Pläne.
Betriebsartefakte:
- Runbooks (Freeze/Grace/Sentinel), Monitoring‑Bots (Forta) mit Alert‑Routing, Incident‑Templates.
- Empfohlene RPC‑/MEV‑Schutzkonfigurationen (Flashbots Protect/MEV Blocker) inkl. Fallbacks. (docs.flashbots.net)
Business‑Deliverables:
- Risiko‑Heatmap (TVL‑bezogen), Remediation‑Roadmap nach Kritikalität, KPI‑Set (MTTD/MTTR, Invarianten‑Abdeckung, Bug‑Bounty‑Time‑to‑Fix).

Häufige Stolpersteine (2025) – Kurzliste zum Selberprüfen

EntryPoint‑Mismatch (4337 v0.6 vs. v0.7) oder fehlende Migrationsplanung. (alchemy.com)
Blindes EIP‑7702‑Delegieren ohne Wallet‑seitige Hard‑Stops/Warnings. (eips.ethereum.org)
Unzureichende Domain‑/Nonce‑Prüfungen bei EIP‑712/SIWE; fehlende ReCaps für „scoped“ Autorisierung. (eips.ethereum.org)
Permit2‑Signaturen ohne Scope/Expiry; keine Nutzer‑Warnungen zu Batch‑Approvals. (github.com)
Fehlende CSP/SRI – anfällig für Frontend‑Supply‑Chain. (developer.mozilla.org)
Kein Notfall‑Freeze/Guardian‑Runbook; keine Forta‑Alarmierung. (governance-v2.aave.com)
Öffentliches Mempool‑Broadcast ohne MEV‑Schutz/Sims; keine Slippage‑Sicherungen. (docs.flashbots.net)

Fazit

Sicherheitsarbeit 2025 bedeutet: präzise, reproduzierbare Tests über alle Schichten – ergänzt durch Notfall‑Kontrollen, Private‑Orderflow‑Strategien und permanentes Monitoring. Wer EIP‑7702/4337‑Spezifika, Upgrades/Guardian‑Mechanismen und Frontend‑Supply‑Chain ernst nimmt, reduziert das Verlustrisiko signifikant – und beschleunigt zugleich Releases durch automatisierte Invarianten, Properties und formale Regeln.

Wenn Sie Ihre dApp/Wallet/API gegen aktuelle Angriffsarten abhärten wollen, liefern wir in 2–4 Wochen einen belastbaren Befund mit Fix‑PRs, Regeln und Betriebssicherungen. Fragen Sie uns nach einem maßgeschneiderten Pentest‑Plan (Scope/TVL/Timeline).