Web3 Anwendungs-Penetrationstests: Leitfaden für deutschsprachige Teams

Kurzbeschreibung: Dieser praxisnahe Leitfaden zeigt, wie deutschsprachige Startups und Enterprise-Teams 2025 moderne Web3-Penetrationstests planen und durchführen – von Smart-Contract-Fuzzing und Invarianten-Tests über Account Abstraction (ERC‑4337/7702) bis zum MEV-/Mempool-Härtung – mit Standards wie OWASP SCSVS und EEA EthTrust v3.

Warum Web3-Pentests 2025 anders sind

Angreifer verlagern ihre Taktiken: 2024 wurden rund 2,2 Mrd. US‑$ entwendet; besonders häufig durch Private‑Key‑Kompromittierungen und Angriffe auf zentralisierte Dienste. 2025 überstiegen die Verluste bereits zur Jahresmitte das 2024er Niveau – mit Einzelfällen im Milliardenbereich. Das macht ganzheitliche Prüfungen (On‑Chain + Off‑Chain) zwingend. (chainalysis.com)
Neue Angriffsflächen durch Ethereum Pectra (Mainnet 07‑Mai‑2025): EIP‑7702 erlaubt EOAs die temporäre Delegation an Code – großartig für UX, aber sicherheitlich relevant für Wallet-/DApp‑Flows und Testfälle. (ethereum.org)

Ergebnis: Ein moderner Web3‑Pentest muss Smart Contracts, dApp-/API‑Backends, Wallets/Mobile‑Apps, Key- und Mempool‑Ops, Bridges und AA‑Infrastruktur als ein zusammenhängendes System behandeln.

Standards, auf die Entscheider achten sollten

OWASP Smart Contract Security Verification Standard (SCSVS, stabile v0.0.1 seit Sep 2024) liefert Kontrollziele speziell für EVM‑Smart‑Contracts und DeFi. Wichtig: OWASP vergibt selbst keine offiziellen SCSVS‑Zertifizierungen – Anbieter dürfen also nicht mit „offiziell OWASP‑zertifiziert“ werben. (owasp.org)
OWASP Smart Contract Top 10 (2025) priorisiert u. a. Access‑Control‑Fehler, Preis‑Oracle‑Manipulationen und Logikfehler – wertvoll zur Risikogewichtung im Test. (owasp.org)
EEA EthTrust Security Levels: Version 3 (März 2025) ist der gegenwärtig gepflegte Katalog konkreter Prüfanforderungen für Solidity; das ältere SWC‑Register wird nicht mehr aktiv gepflegt. Für Audits/Pen‑Tests empfiehlt sich ein Mapping Ihrer Findings auf EthTrust v3. (entethalliance.org)

Geltungsbereich (Scope) für deutschsprachige Teams

Definieren Sie früh, was wirklich „in Scope“ ist. Für Enterprise‑Projekte im DACH‑Raum sehen wir in der Praxis fünf Sicherheitsdomänen:

Smart Contracts (EVM/Vyper): Core‑Protokoll, Token, Module, Upgradability, Admin‑/Timelock‑Governance.
Account Abstraction: ERC‑4337 EntryPoint‑Version, Bundler, Paymaster, Alt‑Mempools; plus EIP‑7702‑Delegation.
Off‑Chain‑Komponenten: Backend‑APIs, Indexer, Relayer, Oracles, Signaturdienste (HSM/MPC/KMS).
Client‑Seite: Web‑Frontends, Browser‑Wallet‑Flows, Mobile‑Apps (OWASP MASVS für iOS/Android). (mas.owasp.org)
Infrastruktur & MEV: RPC/Mempool‑Routing, private Orderflow (Protect RPC), Alerting und Runbooks. (docs.flashbots.net)

Tipp: Verankern Sie im Angebot eine „Scope Freeze“-Phase samt Threat‑Model‑Workshop – sonst testet Ihr Team in bewegliche Ziele.

Vorgehensmodell in 7 Phasen

Vorbereitung
- Dokumente: Architekturdiagramm, Rollen/ACLs, Deployment‑Adressen, Upgrade‑Pfad, Treasury‑/Guardian‑Rollen.
- Standards: Mapping auf OWASP SCSVS/EthTrust v3. (owasp.org)
Threat Modeling
- Fokusflächen 2025: Private‑Key‑/Signer‑Ops (z. B. CI‑Secrets), AA‑Validierungsregeln (ERC‑7562), Mempool/MEV, Oracle‑Integrationen, Cross‑Chain‑Bridges. (eips.ethereum.org)
Testumgebungen aufsetzen
- Mainnet‑Forks (Anvil) für realistische States, Reorg‑Simulationen, Slot‑/Timestamp‑Manipulationen.
- Für Browser-/Mobile‑Flows gesonderte Staging‑RPCs; optional Tenderly Virtual TestNets (als Forks‑Nachfolger). (github.com)
Smart‑Contract‑Analyse (statisch, dynamisch, formal)
- Statisch: Slither in CI (PR‑gating). (github.com)
- Dynamisch: Foundry‑Invarianten, Echidna‑Fuzzing; selektiv Symbolic Execution (Mythril, Manticore). (learnblockchain.cn)
- Formal: ausgewählte kritische Properties mit Certora (z. B. Liquidations‑/Invarianzregeln). (docs.certora.com)
AA‑/Mempool‑/MEV‑Prüfungen
- Bundler‑/Paymaster‑Simulationen gemäß Spec; Alt‑Mempool‑Regeln (ERC‑7562) überprüfen. (docs.erc4337.io)
- Private Orderflow (Flashbots Protect): Frontrun/Sandwich‑Risiko, Fallback „useMempool=true“ nach 25 Blöcken. (docs.flashbots.net)
Off‑Chain‑/Client‑Tests
- API‑AuthZ, Ratelimits, Signatur‑/Nonce‑Handling (EIP‑712/1271), Mobile‑App gem. MASVS. (eip.info)
Reporting & Fix‑Verifikation
- Findings mit reproduzierbaren PoCs, Impact, Exploitability, Remediation, Trace/Tx‑IDs; Mapping zu SCSVS/EthTrust‑Requirements; Retest‑Window und Abnahme.

Praxis: Tiefe Testbausteine, die 2025 wirklich Mehrwert liefern

1) Smart‑Contract‑Testing, das Bugs findet – nicht nur „läuft“

Foundry‑Invarianten für System‑Eigenschaften:
Beispiele: „Gesamt‑Assets ≥ Gesamt‑Supply“, „xy=k in jedem Pfad“, „keine negative Schuld“. Nutzen Sie runs=10 000, depth=128 als Startpunkt, und erhöhen Sie runs in CI‑Profilen per In‑Line‑Konfig (forge‑config pragma in Kommentaren), um regressionssicher zu werden. (learnblockchain.cn)
Fuzzing mit Echidna: Property‑basierte Checks über mehrere Zustandsübergänge; als GitHub Action für jeden PR. Hybrid‑Fuzzing (Echidna+symbolic) erhöht die Path‑Abdeckung bei „schwer zu treffenden“ Kanten. (github.com)
Symbolic Execution punktuell: Mythril für Bytecode‑Wege; Manticore für gezielte Pfade/Hooking. (github.com)
Formal Verification, wenn es „teuer wird“:
- Regeln wie „keine ungecollateralisierten Entnahmen“, „Fee‑Accrual monoton steigend“, „Liquidations‑Discount begrenzt“.
- Certora Prover lässt sich in die Pipeline integrieren; aktuelle Releases (2025) erweitern u. a. Invarianten‑Ausdrücke/Spezifikationssprache. (docs.certora.com)

Tooling‑Stack (Minimal‑Variante):

Slither → Blocker im CI bei High/Critical. (github.com)
Foundry → Unit‑/Invariant‑Tests; Mainnet‑Fork (Anvil). (github.com)
Echidna → Langläufer overnight; Fail‑Corpus archivieren. (blog.trailofbits.com)
Optional: Mythril/Manticore → Deep‑Paths. (github.com)

2) Account Abstraction (ERC‑4337) sicher prüfen

Warum wichtig: AA erweitert den Validierungs‑/Gaszahlungsweg – falsche Annahmen führen zu DoS, Sponsoring‑Missbrauch oder Replay‑Problemen.

Konkrete Prüfungen:

EntryPoint‑Version und Netzwerk‑Adresse verifizieren (z. B. v0.8 Singleton‑Adresse, ältere v0.7/v0.6 unterscheiden) und auf Breaking‑Changes achten. Dokumentieren Sie den Code‑Hash. (github.com)
Bundler‑Pfad: Nur UserOps aufnehmen, die
```
simulateValidation
```
bestehen; Reputation/Throttle gemäß ERC‑7562 prüfen (z. B. BANNED/THROTTLED‑Heuristiken, Gas‑Caps für Validation). (docs.erc4337.io)
Paymaster‑Sicherheit: Stake/Deposit, deterministische
```
validatePaymasterUserOp
```
,
```
postOp
```
‑Gas‑Sicherheit, Sponsoring‑Policies (Whitelist/Rate‑Limit), Replay‑Schutz. (docs.erc4337.io)
EIP‑7702‑Kontexte: Prüfen, dass Delegations‑Adressen in Hashes korrekt berücksichtigt werden und Signaturen keine Packing‑Bypässe erlauben (Paymaster‑Sponsoring‑Missbrauch). (github.com)

Beispiel‑Runbook (Auszug):

Negative Tests: UserOps mit zu geringem
```
preVerificationGas
```
, inkonsistentem
```
nonce
```
, ungültigen Aggregator‑Sigs → Erwartung: Lokale Rejection, kein Gas‑Leak. (docs.erc4337.io)
Alt‑Mempool: Erzwingen Sie Rate‑Limits/Throttle für „Noisy Factories/Paymaster“. (eips.ethereum.org)

3) MEV‑/Mempool‑Härtung für kritische Flows

Private Orderflow per Flashbots Protect RPC in die CI‑/UAT‑DApp einbinden; verifizieren, dass Transaktionen mit MEV‑Wert nicht im Public Mempool landen.
Fallback‑Pfad dokumentieren: „useMempool=true“ (nach ~25 Blöcken ohne Inclusion) – testen Sie Front‑Running‑Risiko, Slippage‑Grenzen, Revert‑Refunds. (docs.flashbots.net)

4) Cross‑Chain/Bridges – besondere Sorgfalt

Replay‑/Domain‑Separation: EIP‑712‑Domain mit chainId und verifyingContract strikt validieren; für Smart‑Wallet‑Signaturen ERC‑1271 durchtesten. (eip.info)
Testen Sie Timeout/Retry‑Logik, Idempotenz und „Funds Locked but Message Lost“‑Szenarien auf geforkten Testnetzen oder VTNs. (docs.tenderly.co)

5) Client & Mobile (Wallet‑Flows)

Phishing/Consent‑Prompts, Transaktionsvorschau, EIP‑712‑Lesbarkeit, Anti‑Blind‑Signaturen.
Mobile‑Apps gegen OWASP MASVS (v2.x) verifizieren – Datenhaltung, Kryptographie, Auth, Resilienz. (mas.owasp.org)

Messbare Deliverables, die CFO/CTO verstehen

Findings mit PoC‑Skripten (forge/cast oder python), reproduzierbare Tx/Trace‑IDs, Worst‑Case‑Exploit‑Pfad, On‑Chain‑Belege.
Coverage‑Metrics:
- Invarianten/Properties abgedeckt (Anzahl, Laufzeiten, Falsifikate),
- Fuzzing‑Corpus (Seeds, Edge‑Coverage),
- Symbolic‑Reachability (kritische Pfade).
Mapping:
- OWASP SCSVS‑Controls erfüllt/nicht erfüllt,
- EthTrust v3 Anforderungen pro Modul (S/M/Q‑Bucket). (owasp.org)

Bonus: Für dApps mit hohen TVL ist eine koordinierte Bug‑Bounty‑Strategie (Immunefi) sinnvoll – Markt zahlt mittlerweile >100 Mio. US‑$ aus; Severity‑Tiers und Token‑Liquiditätsanforderungen beachten. (globenewswire.com)

Emerging Best Practices 2025

Setzen Sie EthTrust v3 als verbindlichen Prüfkatalog; SWC nur noch als Referenzhistorie. (entethalliance.org)
AA‑Sicherheit „by default“: Bundler simulieren strikt; Paymaster nur mit Stake + deterministischer Validierung;
```
FailedOp
```
‑Monitoring. (docs.erc4337.io)
Pectra‑Folgen adressieren: EIP‑7702‑Delegation in Threat‑Models, EntryPoint‑Upgrades (v0.8/v0.9) und EIP‑7562‑Regeln in Test‑Suites berücksichtigen. (github.com)
CI/CD „Security Gates“:
- Slither „High/Critical = Fail“;
- Foundry‑Invarianten im Nightly (runs ≥ 10 000),
- Echidna über Wochenenden/Cloud‑Runners. (github.com)
MEV‑Härtung als Feature: Private RPC standardmäßig aktiv, dokumentierte Fallbacks. (docs.flashbots.net)
Formale Verifikation dort, wo ökonomische Invarianten kritisch sind (Liquidations‑Logik, AMM‑Invarianten, Cross‑Module‑Accounting). Aktuelle Certora‑Releases erleichtern die Integration. (docs.certora.com)

Beispiel: Mini‑Runbooks (Auszug)

DeFi‑Lending‑Modul

Invarianten: Summe der Einlagen − Schulden = Reserven ± Fees; „Health‑Factor < 1 ⇒ Liquidation möglich“.
Fuzzing: Zufalls‑Sequenzen über Deposit/Borrow/Repay/Liquidate; invariants nie verletzt.
Symbolic‑Spotcheck: Zins‑Update bei Grenz‑Werten (u128 Overflow‑Gefahr) mit Manticore. (github.com)
Formal: „Keine ungecollateralisierten Auszahlungen“ (Certora‑Rule). (docs.certora.com)

ERC‑4337‑Paymaster

Negative Tests: Spam von invaliden UserOps → kein Stake‑Drain;
```
postOp
```
limitiert Gas; Sponsoring nur für erlaubte Methoden. (docs.erc4337.io)
7702‑Wechselwirkungen: Delegations‑Target korrekt im UserOp‑Hash; keine Signatur‑Replays durch Packing‑Fehler. (github.com)

DEX‑UI/Router

Private RPC aktiv; Fallback „useMempool=true“ nach 25 Blöcken. Slippage‑Guards, Sandwich‑Resilienz verifiziert. (docs.flashbots.net)
EIP‑712‑Order‑Signaturen lesbar und korrekt domänensepariert; Contract‑Signaturen via ERC‑1271 unterstützt. (eip.info)

Go‑Live‑Security‑Gate (Checkliste)

EthTrust v3‑Mapping ohne „rote“ Lücken für Mainnet‑Scope. (entethalliance.org)
OWASP SCSVS‑Kontrollen für Smart‑Contracts (Kernmodule) erfüllt oder mit Kompensationsmaßnahmen. (owasp.org)
EntryPoint‑Adresse/Version und Bundler‑/Paymaster‑Policies dokumentiert; ERC‑7562‑Konformität geprüft. (eips.ethereum.org)
Private RPC für kritische Flows; Fallback‑Strategie getestet. (docs.flashbots.net)
CI/CD Security Gates: Slither‑Blocker, Invarianten‑Nightly, Fuzzing‑Weekend. (github.com)
Bug‑Bounty‑Programm (Scope/Severities/Payout‑Asset‑Liquidität) live. (immunefisupport.zendesk.com)

Fazit

Web3‑Sicherheit ist 2025 ein Systemthema: Smart Contracts, AA‑Validierung, Mempool/MEV, Off‑Chain‑Ops und Mobile‑UX greifen ineinander. Wer Prüfungen standardbasiert (SCSVS, EthTrust v3), testgetrieben (Invarianten/Fuzzing/Formal) und betriebsnah (AA‑/Mempool‑Policies, Private RPC, Runbooks) organisiert, reduziert nicht nur Exploit‑Risiken – sondern schafft auch die Basis für schnellere Releases und belastbare Compliance‑Nachweise.

Wenn Sie Unterstützung beim Scoping, bei AA‑/MEV‑Härtung oder beim Aufbau eines „Security‑as‑Code“-Stacks benötigen, begleiten wir Sie bei 7Block Labs mit reproduzierbaren Methodiken, Tooling‑Automatisierung und klaren Entscheidungsvorlagen für Ihre C‑Level‑Runden.