Web3 Anwendungs-Penetrationstests: Testfälle für Smart-Account Wallets und Signaturen

Kurzfassung: Dieser Leitfaden zeigt, wie Sie Smart-Account-Wallets (ERC‑4337/Modular Accounts) und deren Signaturpfade realitätsnah penetrieren: von EOA→Smart‑Account‑Delegationen (EIP‑7702) über ERC‑1271/6492/712 bis zu Paymastern, Bundlern, Session Keys und Passkeys. Mit konkreten Testfällen, Sollwerten und Prüfschritten für Enterprise‑Readiness.

---

Warum Smart‑Accounts andere Tests brauchen als klassische EOAs

Smart‑Accounts verschieben Sicherheit von einer einzelnen ECDSA‑Schlüsseldatei in programmierbare Validierungslogik: Signaturprüfung (ERC‑1271), Nonce‑Management, Gaszahlung via Paymaster und modulare Policies laufen im Vertrag. Diese Flexibilität erhöht die Angriffsoberfläche: Fehlkonfigurierte Domain‑Separatoren, fehlerhafte Off‑/On‑Chain‑Hashes, Replay‑Fenster über Accounts/Chains, Paymaster‑Griefing oder Mempool‑DoS. ERC‑4337 definiert dazu eine alternative UserOperation‑Mempool/EntryPoint‑Architektur – Tests müssen den kompletten Pfad abdecken, nicht nur die Signatur. (eips.ethereum.org)

---

Was 2024/2025 neu (und testrelevant) ist

• EntryPoint v0.7: neue PackedUserOperation, getrennte Paymaster‑Gasfelder und strukturierte Validierungsfehler. Prüfen Sie Kompatibilität, Adressen und Migrationspfade (v0.6→v0.7). Offiziell verwendete v0.7‑EntryPoint‑Adresse: 0x0000000071727De22E5E9d8BAf0edAc6f37da032. (github.com)
• EIP‑7702: EOAs können temporär wie Smart‑Accounts handeln; zusätzliche Gas‑Kosten (z. B. PER_EMPTY_ACCOUNT_COST=25 000) müssen in preVerificationGas eingerechnet werden. Testen Sie Delegations‑Flows, Revocation und Kompatibilität mit 4337. (theblock.co)
• ERC‑7562: Validierungs‑Scope‑Regeln schützen Bundler‑Mempools gegen DoS; Reputation/Throttling und Opcode‑Verbote gelten während der Validierung. Muss in Off‑Chain‑Simulation und Monitoring geprüft werden. (eips.ethereum.org)
• ERC‑7769: Standardisierte Bundler‑RPCs (eth_sendUserOperation, Debug‑APIs) – wichtig für Interop‑ und Fuzz‑Tests der Mempool‑Pfadlogik. (eips.ethereum.org)
• Modular‑Standards: ERC‑7579 (minimale Interop‑Interfaces) und ERC‑7484 (Module Registry/Attestations) – Tests müssen Modullade‑/Entfern‑Pfad, Hook‑Kaskaden und Registry‑Prüfungen abdecken. (eips.ethereum.org)

---

Testkatalog A: Signaturen & Identität

A1) ERC‑1271 korrekt (und sicher) implementiert?

Ziele:

• isValidSignature muss bei Erfolg 0x1626ba7e liefern; keine Zustandsänderung; externe Calls nur bewusst.
• Niedrig‑S‑Durchsetzung: ecrecover akzeptiert High‑S historisch, Verträge müssen Low‑S erzwingen (EIP‑2).
  Prüfschritte:

1. Negativtests: falsche Signatur, falscher Hash, falsches MagicValue → stets Fail.
2. Entscheidungslogik Fuzzing: Zeit/State‑abhängige Checks, Fallback‑Handler, Reentrancy.
3. High‑S Signaturen über Fuzzing einspeisen; erwarten: Revert/invalid. (eips.ethereum.org)

A2) EIP‑712 Domain‑Separator: kollisionssicher?

Ziele:

• Domain enthält mindestens chainId und verifyingContract; wallet/dApp verweigert Signatur bei Chain‑Mismatch.
• Verträge veröffentlichen Domain per ERC‑5267 (eip712Domain(), optional Event EIP712DomainChanged).
  Prüfschritte:
• Domain‑Abfrage on‑chain (ERC‑5267), Abgleich gegen lokal verwendete Werte; gezielte Mismatch‑Tests (ChainId, Name/Version).
• Phishing‑Tests: gleicher Typ/Message, anderer verifyingContract → muss scheitern.
• Negative Usability‑Kontrolle: Wallet sollte bei falscher chainId warnen/ablehnen. (eips.ethereum.org)

Extrafall: Viele Wallets haben/hatten ChainId‑Fehler in EIP‑712‑Signaturen; Audit‑Cases aufnehmen. (coinspect.com)

A3) ERC‑6492: Vor‑Deployment‑Signaturen („counterfactual“)

Ziele:

• Login/Signaturen vor Erstdeployment sind valide, indem Signatur‑Wrapper (magicBytes) und factoryCalldata berücksichtigt werden.
  Prüfschritte:
• Prüfen, ob Verifier zuerst nach magicBytes sucht, dann ggf. factory‑Deploy simuliert und erst dann ERC‑1271 prüft.
• Cross‑Network‑Replay absichern (gleiches Factory‑Bytecode/Calldata auf anderer Chain): dApp‑Server müssen Domain/ChainId strikt binden.
• Tooling‑Test: Off‑Chain‑Verifier (z. B. WalletConnect/reown erc6492 crate) gegen eigene Backends. (eips.ethereum.org)

A4) Replay‑Schutz über mehrere Smart‑Accounts hinweg (gleiche EOA)

Ziele:

• Verhindern, dass eine EOA‑Signatur in mehreren eigenen Smart‑Accounts wiederverwendet wird.
  Prüfschritte:
• Nested‑Typed‑Signatures nach ERC‑7739 testen (defensives Re‑Hashing inkl. Account‑Adresse).
• Fuzz: Signatur für Account X gegen Account Y validieren – muss scheitern. (ercs.ethereum.org)

A5) EIP‑7702‑Autorisierungen: EOA→Smart‑Account pro Transaktion

Ziele:

• Delegation nur für den Sender‑Kontext erlaubt; Gas‑Schätzung berücksichtigt zusätzliche Kosten; Revocation sauber.
  Prüfschritte:
• AUTH‑Regeln aus 7562: EIP‑7702‑delegierte Accounts dürfen im UserOp nur als Sender auftreten; Mehrfach‑Authorizations konsistent.
• preVerificationGas enthält 25 000 Zusatzkosten (wenn anwendbar). (eips.ethereum.org)

---

Testkatalog B: UserOperations, Bundler & Mempool

B1) EntryPoint‑Kompatibilität und Versionserkennung

Ziele:

• Wallet/SDK wählen automatisch v0.6 oder v0.7 anhand validateUserOp‑Parameter (UserOperation vs PackedUserOperation).
  Prüfschritte:
• On‑chain ABI‑Check, Adressverifikation (v0.7: 0x000000007172…032), Simulation gegen beide Varianten, Migrationspfad‑Smoke‑Test. (alchemy.com)

B2) UserOperation‑Hashing & Packing

Ziele:

• Keine Divergenzen zwischen Off‑Chain‑Signatur und On‑Chain‑Validierung; packing/offset‑Bugs ausgeschlossen.
  Prüfschritte:
• Differential‑Tests mehrerer Signer/SDKs gegen EntryPoint.getUserOpHash; Mutationstests an initCode/callData.
• Regression: alte Calldata‑Packing‑Schwachstellen (2023) – sicherstellen, dass Fixes aktiv und Tests vorhanden sind. (alchemy.com)

B3) ERC‑7562‑Regeln & DoS‑Resilienz

Ziele:

• Validierungsphase ist deterministisch, ressourcenbegrenzt und isoliert; Reputation/Throttling greift.
  Prüfschritte:
• Trace‑Simulations‑Suite: Banned/Throttled‑Pfad, MAX_USEROP_SIZE/CONTEXT‑Größen, Gas‑Slack‑Einhaltung, Opcode‑Verbote.
• P2P‑Propagations‑Tests mit Shared‑Mempool/isolierten Bundlern; Drop‑/Retry‑Pfad validieren. (eips.ethereum.org)

B4) Bundler‑RPC‑Interop (ERC‑7769)

Ziele:

• Einheitliche Fehlercodes/Debug‑RPCs; Wallets/SDKs gegen mehrere Bundler austauschbar.
  Prüfschritte:
• Conformance‑Suite für eth_sendUserOperation + Debug‑RPC; Fuzzing mit ungültigen Feldern/Nonces; Logging der Ablehnungsgründe. (eips.ethereum.org)

---

Testkatalog C: Paymaster, Gebühren & Abrechnung

C1) Stake/Deposit‑Pfad & Sicherheitslogik

Ziele:

• Paymaster ist gestaked, hat ausreichenden Deposit; withdraw/unstake‑Delays korrekt; Griefing‑Risiken minimiert.
  Prüfschritte:
• EntryPoint: getDepositInfo/balanceOf/depositTo/addStake/withdrawStake round‑trip Tests; Reverts bei Unterdeckung.
• Lasttests mit fehlschlagenden Ops → Paymaster zahlt wie erwartet; PostOp‑Abrechnung robust. (eips.exposed)

C2) v0.7‑Spezifika: paymasterGasLimit/postOp‑Gas

Ziele:

• Getrennte Gaslimits für Paymaster‑Validierung/PostOp korrekt gesetzt; Bundler‑Schätzung konsistent.
  Prüfschritte:
• Signatur‑/Stub‑Fluss über pm_getPaymasterStubData/pm_getPaymasterData (ERC‑7677) – EntryPoint‑Version erkennen und Felder korrekt befüllen. (hackmd.io)

C3) Historische Packing‑Issues (Awareness‑Tests)

Ziele:

• Schutz vor Hash‑Divergenzen, bei denen initCode/callData nach Signatur manipuliert werden konnten.
  Prüfschritte:
• Reproduktions‑Tests der 2023er‑Schwachstelle gegen gepatchte Entrypoints/Paymaster‑Beispiele; negative Sponsoring‑Versuche. (alchemy.com)

---

Testkatalog D: Modulare Smart‑Accounts, Module‑Registries & Session Keys

D1) Interop‑Checks (ERC‑7579) und Registry (ERC‑7484)

Ziele:

• Module‑Install/Uninstall, Hook‑Kaskaden, Fallback‑Handler, Executor/Validator‑Wege – alles standardkonform und registry‑geprüft.
  Prüfschritte:
• Module‑Attestation via Registry‑Adapter (ERC‑7484), Blockieren unsignierter/unattestierter Module, Zeit‑Lock/Resource‑Lock Policies evaluieren. (eips.ethereum.org)

D2) Session Keys: granular, ablaufend, kettenübergreifend

Ziele:

• Temporäre Schlüssel mit Policies (Zeitfenster, Ziel‑Whitelist, Limits) funktionieren über Konten/Chains konsistent.
  Prüfschritte:
• Session‑Manager‑Module (z. B. SmartSession) einsetzen; Mehrketten‑Policy‑Durchsetzung; explizite Revoke‑/Expiry‑Tests. (rhinestone.dev)

D3) Passkeys/WebAuthn (P‑256) – RIP/EIP‑7212

Ziele:

• P‑256‑Verifikation on‑chain vorhanden (RIP/EIP‑7212 Precompile, Address/Cost), korrekte Einbindung in validateUserOp.
  Prüfschritte:
• Chain‑Capabilities ermitteln; Fallback auf Software‑Verifier falls Precompile fehlt; Gas‑Kosten im preVerificationGas berücksichtigen.
• End‑to‑End‑Flows mit WebAuthn‑API signieren und on‑chain prüfen. (eip.info)

---

Testkatalog E: Censorship‑Resistenz, MEV & „Private“ Pfade

Ziele:

• UserOps erreichen zuverlässig die (Shared) Alt‑Mempool‑Peers; kein Single‑Bundler‑Lock‑in; optional Private‑Submission für sensitive Flows.
  Prüfschritte:
• Parallele Einreichung an mehrere Bundler; Shared‑Mempool‑Presence prüfen; Status‑Konsistenz über RPCs.
• Für vertrauliche Aktionen experimentell private/verschlüsselte Pfade evaluieren; Grenzen in 4337 beachten. (docs.erc4337.io)

---

Praxisnahe Beispiel‑Szenarien (mit konkreten Checks)

Beispiel 1: „Login vor Deployment“ mit ERC‑6492

• Flow: dApp fordert Sign‑In; Smart‑Account noch nicht deployed → 6492‑Wrapper + factoryCalldata verwenden.
• Checks:
  • Server verifiziert magicBytes zuerst, simuliert factory‑Deploy, ruft danach isValidSignature.
  • Replay‑Schutz: EIP‑712‑Domain enthält chainId & verifyingContract; Cross‑Chain‑Versuche schlagen fehl. (eips.ethereum.org)

Beispiel 2: EOA‑Wallet „als“ Smart‑Account (EIP‑7702) für Batch‑Kauf

• Flow: EOA signiert Autorisierung, Wallet führt Batch via wallet_sendCalls (EIP‑5792) mit Paymaster‑Capability aus.
• Checks:
  • preVerificationGas enthält 7702‑Autorisierungskosten; AUTH‑Regeln aus 7562 eingehalten.
  • EIP‑5792: Wallet meldet paymasterService‑Capability; App übergibt URL/Context → pm_getPaymasterData liefert korrekte Felder v0.6/v0.7. (eip.info)

Beispiel 3: Passkey‑gesicherte In‑App‑Käufe

• Flow: WebAuthn‑Signatur (P‑256) → validateUserOp prüft p256 (Precompile oder Solidity‑Verifier), Session‑Key auf 24 h begrenzt.
• Checks:
  • Kette unterstützt RIP/EIP‑7212 (Precompile 0x0100, typische Verifikationskosten ~3 450 Gas).
  • Session‑Key‑Policy: Ziel‑Whitelist, Spending‑Cap, Ablauf; Revoke‑Pfad. (ritualfoundation.org)

Beispiel 4: Paymaster‑gesponserte Free‑Trial‑Aktionen

• Flow: dApp sponsert Erstaktionen; PM‑Stub‑Daten für Gas‑Schätzung; final pm_getPaymasterData signiert.
• Checks:
  • Deposit/Stake ausreichend; Revert‑Kosten werden vom Paymaster getragen und korrekt verbucht.
  • v0.7‑Felder paymasterVerificationGasLimit/paymasterPostOpGasLimit korrekt gesetzt. (eips.ethereum.org)

---

Metriken & Beweisführung für Management‑Reports

• Signatur‑Robustheit
  • Anteil abgewiesener Kollisionstests (712‑Domain‑Mismatch, 7739‑Replay‑Versuche).
• UserOp‑Reliabilität
  • Simulations‑Erfolgsquote, First‑Inclusion‑Rate, Ablehnungsgründe (7769‑konforme Fehlercodes). (eips.ethereum.org)
• Mempool‑Gesundheit
  • Shared‑Mempool‑Propagation vs. Single‑Bundler; Drop‑/Retry‑Quoten unter 7562‑Regeln. (eips.ethereum.org)
• Paymaster‑Risikokennzahlen
  • Gas pro gesponserter Aktion, Revert‑Quote, Deposit‑Coverage in Blöcken (Worst‑Case).
• Modul‑Compliance
  • Anteil installierter Module mit gültigen ERC‑7484‑Attestationen; Mean‑Time‑to‑Revoke.

---

Tooling & Automatisierung (schnell integrierbar)

• Bundler/Paymaster/Accounts via permissionless.js (vendor‑agnostisch, viem‑basiert) fuzz‑en und conformance‑testen.
• OpenZeppelin Accounts/Utils für eigene Smart‑Account‑Implementierungen; CI‑Tests für validateUserOp/1271/7579. (docs.pimlico.io)
• EIP‑5792 Testharness: wallet_getCapabilities/paymasterService/atomic‑Flows stichprobenartig prüfen. (eips.ethereum.org)

---

„Best Emerging Practices“ für 2025‑Rollouts

• Signaturen
  • Immer ERC‑5267 implementieren; in Backends Domain live abfragen statt statisch zu konfigurieren. (eips.ethereum.org)
  • Low‑S‑Check in Verträgen erzwingen; 712‑Signaturen mit vollständiger Domain (inkl. chainId & verifyingContract). (eips.ethereum.org)
  • Für Counterfactual‑Flows 6492 konsequent einsetzen und Cross‑Chain‑Replays explizit blocken. (eips.ethereum.org)
• UserOps
  • EntryPoint v0.7 bevorzugen; Migrationsfenster mit Dual‑Support (v0.6/v0.7) planen. (outposts.io)
  • 7562‑Konformität als CI‑Gate (Opcode‑Verbote, Größenlimits, Reputations‑Trigger). (eips.ethereum.org)
  • 7769‑RPC für portable Wallet/Bundler‑Tests nutzen; Ablehnungs‑Telemetry standardisieren. (eips.ethereum.org)
• Paymaster
  • ERC‑7677 integrieren; Stub‑Daten für präzise Gas‑Schätzungen; PostOp‑Kosten durch Paymaster selbst schätzen/setzen (v0.7). (eips.ethereum.org)
  • Deposits/Stake‑Monitoring mit automatischen Top‑ups; Policies gegen „sponsored griefing“. (docs.erc4337.io)
• Modularität
  • ERC‑7579 als Mindeststandard; nur Module mit 7484‑Attestationen; Session‑Keys mit klaren Policy‑Bundles (Limit/Scope/Expiry). (eips.ethereum.org)
• Passkeys
  • Wo verfügbar: RIP/EIP‑7212 nutzen (Gas/Kompabilität testen); andernfalls geprüfte On‑Chain‑Verifier. (eip.info)

---

Kurz‑Checkliste für Ihren nächsten Pentest‑Sprint

• Vorab
  • Threat‑Model je Use‑Case (Login, Payment, Automationen).
  • Chain‑Fähigkeiten (7702/7212/EntryPoint‑Version) erfassen. (alchemy.com)
• Signaturen
  • ERC‑1271/5267/712/6492/7739‑Testsuite ausführen (Replay, Domain‑Mismatch, Counterfactual, Low‑S). (eips.ethereum.org)
• UserOps
  • getUserOpHash‑Vergleiche; 7562‑Konformität; 7769‑RPC‑Interop; Mehr‑Bundler‑Einreichung. (eips.ethereum.org)
• Paymaster
  • Stake/Deposit‑Round‑Trip; v0.7‑Gasfelder; 7677‑Stub/Data; Revert‑Kostenschutz. (hackmd.io)
• Modularität
  • 7579‑Interfaces, Hook‑Kaskaden, Registry‑Attestationen (7484), Session‑Key‑Revocation. (eips.ethereum.org)
• Passkeys
  • 7212‑Precompile vorhanden? WebAuthn‑End‑to‑End; preVerificationGas anpassen. (ritualfoundation.org)

---

Fazit

Für Entscheider ist die Botschaft klar: Smart‑Account‑Sicherheit misst sich nicht mehr nur an der Kryptografie, sondern an End‑to‑End‑Pfaden – Domain‑Separierung, modulare Validierung, Mempool‑Verhalten und Kostenkontrollen. Wer 2025 produktionsreif launchen will, etabliert 7562‑konforme Simulationen, 7769‑RPC‑Interop‑Tests, 7579/7484‑Modul‑Governance und 7212‑fähige Passkey‑Flows – plus Paymaster‑Sponsoring mit 7677‑Kompatibilität. So wird aus Wallet‑UX ein belastbares Unternehmens‑System. (eips.ethereum.org)

---