Web3 Anwendungs-Penetrationstests: Leitfaden für deutschsprachige Teams

Kurzbeschreibung

Dieser praktische Leitfaden erklärt, wie deutschsprachige Startups und große Teams im Jahr 2025 moderne Web3-Penetrationstests aufstellen und umsetzen. Wir decken alles ab, von Smart-Contract-Fuzzing und Invarianten-Tests bis hin zu Account Abstraction (ERC‑4337/7702) und der Härtung von MEV/Mempool. Dabei orientieren wir uns an Standards wie OWASP SCSVS und EEA EthTrust v3.

---

Warum Web3-Pentests 2025 anders sind

• Angreifer haben ihre Spielzüge angepasst: Im Jahr 2024 wurden stolze 2,2 Milliarden US-Dollar gestohlen, wobei Privat-Key-Kompromittierungen und Angriffe auf zentralisierte Dienste besonders häufig auftraten. Bereits Mitte 2025 hatten die Verluste das Niveau von 2024 übertroffen - einige Fälle lagen sogar im Milliardenbereich. Daher sind umfassende Prüfungen (On-Chain + Off-Chain) jetzt unerlässlich. (chainalysis.com)
• Neue Angriffsmöglichkeiten durch Ethereum Pectra (Mainnet am 07. Mai 2025): Mit EIP-7702 können EOAs temporär an Code delegiert werden - das sorgt für eine bessere Benutzererfahrung, hat aber auch sicherheitliche Implikationen für Wallet-/DApp-Flows und Testfälle. (ethereum.org)

Ergebnis: Bei einem modernen Web3-Pentest sollte man Smart Contracts, dApp-/API-Backends, Wallets/Mobile-Apps, Key- und Mempool-Operationen, Bridges und die AA-Infrastruktur als ein zusammenhängendes System betrachten.

---

Standards, auf die Entscheider achten sollten

• Die OWASP Smart Contract Security Verification Standard (SCSVS, stabile Version v0.0.1 seit September 2024) gibt eine tolle Übersicht über Kontrollziele, die sich speziell auf EVM-Smart-Contracts und DeFi konzentrieren. Ein wichtiger Punkt: OWASP selbst bietet keine offiziellen SCSVS-Zertifizierungen an. Also, falls jemand mit „offiziell OWASP-zertifiziert“ wirbt, könnt ihr das getrost ignorieren. (owasp.org)
• Die OWASP Smart Contract Top 10 (2025) hebt einige wichtige Themen hervor, wie zum Beispiel Access-Control-Fehler, Preis-Oracle-Manipulationen und Logikfehler. Das ist super nützlich, um die Risiken bei euren Tests richtig einzuschätzen. (owasp.org)
• Die EEA EthTrust Security Levels: Version 3 (März 2025) ist das aktuelle Nachschlagewerk für spezifische Prüfanforderungen in Solidity. Das ältere SWC-Register wird nicht mehr aktiv gepflegt, also verlasst euch da besser nicht mehr drauf. Wenn ihr Audits oder Pen-Tests durchführt, wäre es schlau, eure Ergebnisse auf EthTrust v3 abzugleichen. (entethalliance.org)

---

Geltungsbereich (Scope) für deutschsprachige Teams

Definieren Sie früh, was wirklich „in Scope“ ist. Im DACH-Raum beobachten wir bei Enterprise-Projekten oft fünf zentrale Sicherheitsdomänen:

1. Smart Contracts (EVM/Vyper): This covers the core protocol, tokens, modules, and upgradability, along with admin and timelock governance.
2. Account Abstraction: We’re talking about the ERC-4337 EntryPoint version, bundlers, paymasters, and alternative mempools, not to mention EIP-7702 delegation.
3. Off-Chain Components: Here, you'll find backend APIs, indexers, relayers, oracles, and signature services like HSM, MPC, and KMS.
4. Client Side: This includes web frontends, browser wallet flows, and mobile apps. Make sure to check out the OWASP MASVS for iOS and Android. (mas.owasp.org)
5. Infrastructure & MEV: We’re looking at RPC/mempool routing, private order flow (to protect RPC), alerting, and runbooks. (docs.flashbots.net)

Tipp: Bauen Sie in Ihr Angebot eine „Scope Freeze“-Phase ein, zusammen mit einem Threat-Model-Workshop - andernfalls testet Ihr Team ständig an sich ändernden Zielen.

---

Vorgehensmodell in 7 Phasen

1. Vorbereitung

• Dokumente: Architekturdiagramm, Rollen/ACLs, Deployment-Adressen, Upgrade-Pfad, Treasury-/Guardian-Rollen.
• Standards: Mapping auf OWASP SCSVS/EthTrust v3. (owasp.org)

2. Threat Modeling

• Fokusflächen 2025: Private-Key-/Signer-Ops (wie CI-Secrets), AA-Validierungsregeln (ERC-7562), Mempool/MEV, Oracle-Integrationen und Cross-Chain-Bridges. (eips.ethereum.org)

3. Testumgebungen aufsetzen

• Hauptnetz-Forks (Anvil) für realistische Zustände, Reorg-Simulationen und Slot-/Timestamp-Manipulationen.
• Für Browser- und Mobile-Flows gibt's spezielle Staging-RPCs; als Bonus können auch Tenderly Virtual TestNets verwendet werden (sind die Nachfolger der Forks). (github.com)

4. Smart-Contract-Analyse (statisch, dynamisch, formal)

• Statisch: Slither in CI (PR-gating). Check it out here.
• Dynamisch: Nutze Foundry-Invarianten und Echidna-Fuzzing; außerdem kannst du selektiv Symbolic Execution mit Mythril oder Manticore ausprobieren. Für mehr Infos, klick mal hier.
• Formal: Hier geht’s um ausgewählte kritische Properties, die du mit Certora prüfen kannst (zum Beispiel Liquidations- und Invarianzregeln). Hier sind die Details: docs.certora.com.

5. AA‑/Mempool‑/MEV‑Checks

• Simulate Bundler‑/Paymaster according to spec; check out the old Mempool rules (ERC‑7562). You can find more details here.
• For Private Orderflow (Flashbots Protect), be aware of frontrunning/sandwich risks and remember to fallback to “useMempool=true” after 25 blocks. More info is available here.

1. Off-Chain / Client Tests
   • API AuthZ, rate limits, signature/nonce handling (EIP-712/1271), Mobile App gem. MASVS. (eip.info)

7. Reporting & Fix-Verifikation

• Hier stehen die Ergebnisse mit nachweisbaren PoCs, dem Einfluss, der Ausnutzbarkeit, der Behebung, den Trace/Tx-IDs, und die Zuordnung zu SCSVS/EthTrust-Anforderungen. Außerdem gibt's das Retest-Fenster und die 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:
  Hier sind ein paar Beispiele: „Gesamt-Assets ≥ Gesamt-Supply“, „xy=k in jedem Pfad“ und „keine negative Schuld“. Starte mit runs=10 000 und depth=128, und steigere die Anzahl der Runs in CI-Profilen über die In-Line-Konfiguration (schau dir dazu das forge-config Pragma in den Kommentaren an), damit du regressionssicher bist. (learnblockchain.cn)
• Fuzzing mit Echidna: Hier kannst du property-basierte Checks über verschiedene Zustandsübergänge einbauen; idealerweise als GitHub Action für jeden PR. Wenn du Hybrid-Fuzzing (Echidna + symbolisch) nutzt, verbesserst du die Path-Abdeckung, besonders bei diesen „schwer zu treffenden“ Kanten. (github.com)
• Symbolic Execution punktuell: Mythril ist super für Bytecode-Wege und Manticore eignet sich perfekt für spezifische Pfade/Hooking. (github.com)
• Formal Verification, wenn es „teuer wird“:
  Hier solltest du Regeln im Auge behalten wie „keine ungecollateralisierten Entnahmen“, „Fee-Accrual monoton steigend“ und „Liquidations-Discount begrenzt“. Der Certora Prover lässt sich ganz einfach in deine Pipeline integrieren; die aktuellen Releases (2025) erweitern unter anderem die Invarianten-Ausdrücke/Spezifikationssprache. (docs.certora.com)

Tooling-Stack (Minimal-Variante)

• Slither → Set it up to block your CI if it spots any High or Critical issues. Check it out here.
• Foundry → Great for running unit and invariant tests, plus you can do a Mainnet-Fork using Anvil. Take a look here.
• Echidna → This one's perfect for overnight runs; don't forget to archive your Fail-Corpus! More info can be found here.
• Optional: Mythril/Manticore → Use these for digging deep into paths. Check them out here.

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

Warum das wichtig ist

Die AA (Account Abstraction) erweitert den Validierungs- und Gaszahlungsweg. Wenn wir hier falsche Annahmen treffen, können wir ziemlich schnell in Schwierigkeiten geraten - dazu zählen DoS-Attacken, Missbrauch von Sponsoring und auch Replay-Probleme.

Konkrete Prüfungen:

• Überprüfe die EntryPoint-Version und die Netzwerk-Adresse. Zum Beispiel, achte darauf, dass du die v0.8 Singleton-Adresse verwendest und die alten v0.7/v0.6-Versionen unterscheiden kannst. Vergiss nicht, auf Breaking-Changes zu achten und dokumentiere den Code-Hash. (github.com)
• Für den Bundler-Pfad: Nimm nur UserOps auf, die simulateValidation bestehen. Außerdem solltest du die Reputation und das Throttling gemäß ERC‑7562 prüfen, wie zum Beispiel BANNED/THROTTLED-Heuristiken und Gas-Caps für die Validierung. (docs.erc4337.io)
• Bei der Paymaster-Sicherheit schau dir die Stake/Deposit-Anforderungen an, die deterministische validatePaymasterUserOp, die Gas-Sicherheit bei postOp und die Sponsoring-Politiken (Whitelist/Rate-Limit) an. Und vergiss nicht den Replay-Schutz. (docs.erc4337.io)
• EIP‑7702-Kontexte: Stelle sicher, dass die Delegations-Adressen in den Hashes korrekt berücksichtigt werden und dass die Signaturen keine Packing-Bypässe zulassen, um Missbrauch beim Paymaster-Sponsoring zu vermeiden. (github.com)

Beispiel‑Runbook (Auszug)

• Negative Tests: Hier schauen wir uns UserOps an, die entweder zu wenig preVerificationGas, inkonsistente nonce-Werte oder ungültige Aggregator‑Sigs aufweisen. Was wir erwarten, ist eine lokale Ablehnung, ohne dass Gas verloren geht. Schaut euch die Details hier an!
• Alt‑Mempool: Hier geht’s darum, Rate-Limits oder Throttling für „Noisy Factories/Paymaster“ durchzusetzen. Mehr dazu findet ihr hier.

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

• Binde den Private Orderflow über die Flashbots Protect RPC in die CI-/UAT-DApp ein und schau dir an, ob die Transaktionen mit MEV-Wert nicht im öffentlichen Mempool landen.
• Dokumentiere den Fallback-Pfad: Setze „useMempool=true“ (nach etwa 25 Blöcken ohne Inclusion) und teste dabei das Risiko von Front-Running, die Slippage-Grenzen und die Revert-Refunds. (docs.flashbots.net)

4) Cross‑Chain/Bridges - besondere Sorgfalt

• Replay-/Domain-Separation: Stellt sicher, dass das EIP-712-Domain mit dem chainId und dem verifyingContract vernünftig validiert wird. Außerdem solltet ihr die Signaturen von Smart-Wallets mit ERC-1271 auf Herz und Nieren prüfen. (eip.info)
• Testet die Timeout-/Retry-Logik, Idempotenz und Szenarien wie „Funds Locked but Message Lost“ auf geforkten Testnetzen oder in VTNs. (docs.tenderly.co)

5) Client & Mobile (Wallet‑Flows)

• Phishing und Consent-Prompts, Vorschau von Transaktionen, Lesbarkeit von EIP-712, Anti-Blind-Signaturen.
• Mobile Apps gegen die OWASP MASVS (v2.x) prüfen - dabei geht's um Datenhaltung, Kryptografie, Authentifizierung und Resilienz. (mas.owasp.org)

---

Messbare Deliverables, die CFO/CTO verstehen

• Ergebnisse mit PoC-Skripten (forge/cast oder python), reproduzierbare Tx/Trace-IDs, Worst-Case-Exploit-Pfade und On-Chain-Belege.
• Coverage-Metriken:
  • Abgedeckte Invarianten/Properties (Anzahl, Laufzeiten, Falsifikate),
  • Fuzzing-Corpus (Seeds, Edge-Coverage),
  • Symbolische Erreichbarkeit (kritische Pfade).
• Mapping:
  • OWASP SCSVS-Kontrollen: erfüllt oder nicht erfüllt,
  • EthTrust v3 Anforderungen pro Modul (S/M/Q-Bucket). (owasp.org)

Bonus: Wenn's um dApps mit hohem TVL geht, macht eine koordinierte Bug-Bounty-Strategie über Immunefi echt Sinn. Der Markt hat mittlerweile über 100 Millionen US-Dollar ausgezahlt! Vergiss nicht, die Severity-Tiers und die Token-Liquiditätsanforderungen im Auge zu behalten. (globenewswire.com)

---

Emerging Best Practices 2025

• Nutze EthTrust v3 als verbindlichen Prüfkatalog; SWC dient nur noch als Referenz. (entethalliance.org)
• AA‑Sicherheit „by default“: Bundler sollten stringent simuliert werden; Paymaster nur mit Stake plus deterministischer Validierung und FailedOp-Monitoring. (docs.erc4337.io)
• Pectra‑Folgen anpacken: EIP‑7702‑Delegation in den Bedrohungsmodellen, EntryPoint‑Upgrades (v0.8/v0.9) und EIP‑7562‑Regeln sollten in den Test-Suites beachtet werden. (github.com)
• CI/CD „Security Gates“:
  • Slither „High/Critical = Fail“;
  • Foundry-Invarianten in der Nightly (Runs ≥ 10 000),
  • Echidna über die Wochenenden/Cloud-Runners. (github.com)
• MEV‑Härtung als Feature: Private RPC sollte standardmäßig aktiv sein, mit dokumentierten Fallbacks. (docs.flashbots.net)
• Formale Verifikation dort, wo die wirtschaftlichen Invarianten besonders wichtig sind (wie Liquidations-Logik, AMM-Invarianten und Cross-Module-Accounting). Die aktuellen Certora-Releases machen die Integration einfacher. (docs.certora.com)

---

Beispiel: Mini‑Runbooks (Auszug)

1) DeFi-Lending-Modul

• Invarianten: Wenn wir die Summe der Einlagen nehmen und die Schulden abziehen, sollten wir Reserven plus oder minus Gebühren erhalten. Wenn der „Health-Factor“ unter 1 fällt, könnte eine Liquidation anstehen.
• Fuzzing: Hier testen wir mit zufälligen Sequenzen wie Einzahlen, Ausleihen, Zurückzahlen und Liquidieren. Dabei haben wir beobachtet, dass die Invarianten nie verletzt wurden.
• Symbolic-Spotcheck: Bei den Zins-Updates haben wir Grenzwerte im Blick (das Risiko eines u128 Overflows) mithilfe von Manticore. (github.com)
• Formal: Es gibt „keine ungecollateralisierten Auszahlungen“, das ist eine Regel von Certora. (docs.certora.com)

ERC‑4337‑Paymaster

• Negative Tests: Spam von ungültigen UserOps führt nicht zu einem Stake‑Drain; der postOp-Call hat eine Gas-Limitierung; Sponsoring ist nur für die erlaubten Methoden möglich. (docs.erc4337.io)
• 7702‑Wechselwirkungen: Das Delegations‑Target wird korrekt im UserOp‑Hash behandelt; keine Signatur‑Replays durch Packing‑Fehler. (github.com)

3) DEX‑UI/Router

• Private RPC ist aktiv, und nach 25 Blöcken gibt’s einen Fallback mit „useMempool=true“. Slippage-Guards sind eingerichtet und die Sandwich-Resilienz wurde überprüft. (docs.flashbots.net)
• EIP‑712‑Order‑Signaturen sind lesbar und richtig domänensepariert; die Vertrags-Signaturen unterstützen ERC‑1271. (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) sind erfüllt oder wir haben passende Kompensationsmaßnahmen. (owasp.org)
• EntryPoint‑Adresse/Version und Bundler‑/Paymaster‑Policies sind dokumentiert; die ERC‑7562‑Konformität wurde geprüft. (eips.ethereum.org)
• Private RPC für kritische Flows eingerichtet; Fallback‑Strategie ist getestet. (docs.flashbots.net)
• CI/CD Security Gates: Slither‑Blocker, Invarianten‑Nightly, Fuzzing‑Weekend laufen. (github.com)
• Bug‑Bounty‑Programm (Scope/Severities/Payout‑Asset‑Liquidität) ist jetzt live. (immunefisupport.zendesk.com)

---

Fazit

Web3-Sicherheit wird 2025 zum Systemthema

Im Jahr 2025 wird Web3-Sicherheit echt ein ganzheitliches Thema. Da spielen Dinge wie Smart Contracts, AA-Validierung, Mempool/MEV, Off-Chain-Operations und Mobile-UX alle zusammen. Wenn man Prüfungen auf standardbasierte Methoden (wie SCSVS und EthTrust v3), testgetriebene Ansätze (wie Invarianten, Fuzzing und formale Tests) und betriebsnahe Strategien (wie AA-/Mempool-Policies, Private RPC und Runbooks) organisiert, kann man nicht nur die Risiken von Exploits reduzieren. Man legt auch den Grundstein für schnellere Releases und zuverlässige Compliance-Nachweise.

Wenn Sie Hilfe beim Scoping, bei der AA-/MEV-Härtung oder beim Aufbau eines „Security-as-Code“-Stacks brauchen, sind wir von 7Block Labs für Sie da. Wir bieten Ihnen bewährte Methoden, automatisierte Tools und einfache Entscheidungsvorlagen, die Ihre C-Level-Runden unterstützen.