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

Kurzfassung

In diesem Leitfaden erfährst du, wie du Smart-Account-Wallets (ERC-4337/Modular Accounts) und deren Signaturpfade realistisch durchleuchten kannst. Wir decken alles ab: von EOA zu Smart-Account-Delegationen (EIP-7702), einschließlich ERC-1271, 6492, 712, bis hin zu Paymastern, Bundlern, Session Keys und Passkeys. Du bekommst konkrete Testfälle, Sollwerte und Prüfschritte, die für die Enterprise-Readiness nötig sind.

---

Warum Smart‑Accounts andere Tests brauchen als klassische EOAs

Smart-Accounts verlagern die Sicherheit von einer einzelnen ECDSA-Schlüsseldatei hin zu programmierbarer Validierungslogik. Dabei kommen Sachen wie Signaturprüfung (ERC-1271), Nonce-Management, Gaszahlungen über einen Paymaster und modulare Richtlinien ins Spiel, die direkt im Vertrag laufen. Das klingt cool, aber diese Flexibilität bringt auch neue Herausforderungen mit sich. Zum Beispiel kann es zu fehlkonfigurierten Domain-Separatoren, fehlerhaften Off-/On-Chain-Hashes, Replay-Fenstern über Accounts oder Chains, Paymaster-Griefing oder Mempool-DoS kommen.

Um damit umzugehen, definiert ERC-4337 eine alternative UserOperation-Mempool/EntryPoint-Architektur. Bei Tests ist es wichtig, den gesamten Prozess abzudecken und nicht nur die Signatur. Wenn du mehr darüber wissen möchtest, schau dir die Details hier an: (eips.ethereum.org).

---

Was 2024/2025 neu (und testrelevant) ist

• EntryPoint v0.7: Es gibt jetzt eine neue PackedUserOperation, separate Paymaster-Gasfelder und eine strukturierte Fehlerberichterstattung für die Validierung. Vergessen Sie nicht, die Kompatibilität, Adressen und Migrationspfade (von v0.6 nach v0.7) zu prüfen. Die offiziell genutzte v0.7 EntryPoint-Adresse ist: 0x0000000071727De22E5E9d8BAf0edAc6f37da032. (github.com)
• EIP-7702: Jetzt können EOAs vorübergehend wie Smart Accounts agieren, aber beachten Sie, dass zusätzliche Gas-Kosten (wie PER_EMPTY_ACCOUNT_COST=25000) in das preVerificationGas einkalkuliert werden müssen. Stellen Sie sicher, dass Sie die Delegationsflüsse, Rücknahmen und die Kompatibilität mit 4337 testen. (theblock.co)
• ERC-7562: Neue Validierungs-Scope-Regeln wurden eingeführt, um Bundler-Mempools vor DoS-Attacken zu schützen. Während der Validierung gelten Reputation/Throttle-Regeln und bestimmte Opcode-Verbote. Das muss unbedingt in einer Off-Chain-Simulation und beim Monitoring getestet werden. (eips.ethereum.org)
• ERC-7769: Standardisierte Bundler-RPCs (wie eth_sendUserOperation und Debug-APIs) sind jetzt da - super wichtig für Interoperabilität und Fuzz-Tests der Mempool-Pfadlogik. (eips.ethereum.org)
• Modular-Standards: Es gibt jetzt ERC-7579 (minimale Interop-Interfaces) und ERC-7484 (Module Registry/Attestations). Die Tests sollten den Modul-Lade- und Entfernungs-Pfad, Hook-Kaskaden und die Registry-Checks abdecken. (eips.ethereum.org)

---

Testkatalog A: Signaturen & Identität

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

Ziele:

• Die Funktion isValidSignature sollte bei erfolgreicher Ausführung den Wert 0x1626ba7e zurückgeben; es darf keine Zustandsänderung geben, und externe Aufrufe sollten nur absichtlich gemacht werden.
• Low-S-Durchsetzung: ecrecover hat in der Vergangenheit High-S akzeptiert, aber Verträge müssen jetzt Low-S durchsetzen (EIP-2).

Prüfschritte:

1. Negativtests: Teste falsche Signaturen, falsche Hashes und falsche MagicValues → das sollte immer scheitern.
2. Entscheidungslogik Fuzzing: Überprüfe zeit- oder zustandsabhängige Checks, Fallback-Handler und Reentrancy-Sicherheit.
3. High-S Signaturen via Fuzzing einfüttern; wir erwarten: Revert oder ungültig. (eips.ethereum.org)

A2) EIP‑712 Domain‑Separator: kollisionssicher?

Ziele:

• Die Domain muss mindestens die chainId und verifyingContract enthalten; die Wallet oder dApp sollte die Signatur bei einer Chain-Mismatch ablehnen.
• Verträge sollen die Domain über ERC-5267 veröffentlichen (also mit der Funktion eip712Domain()) und optional ein Event EIP712DomainChanged auslösen.

Prüfschritte:

• Mach eine Domain-Abfrage on-chain (mit ERC-5267) und vergleiche das mit den lokal verwendeten Werten. Hier solltest du gezielte Mismatch-Tests machen (also mit ChainId, Name und Version).
• Führe Phishing-Tests durch: Wenn du einen gleichartigen Typ oder Message, aber einen anderen verifyingContract verwendest, dann sollte der Test fehlschlagen.
• Negative Usability-Kontrolle: Die Wallet muss bei einer falschen chainId eine Warnung ausgeben oder die Transaktion ablehnen. Schau dir dazu mehr auf eips.ethereum.org an!

Extrafall: Wallets mit ChainId-Problemen in EIP-712-Signaturen

In letzter Zeit haben viele Wallets mit einem ChainId-Fehler in EIP-712-Signaturen zu kämpfen gehabt. Das ist natürlich alles andere als optimal! Es ist wichtig, diese Audit-Fälle zu berücksichtigen und sicherzustellen, dass alles reibungslos läuft.

Für weitere Informationen zu diesem Thema, schau dir den Artikel auf coinspect.com an.

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

Ziele:

• Vor dem ersten Deployment müssen die Login/Signaturen gültig sein, und dabei sollten wir die Signatur-Wraps (magicBytes) und das factoryCalldata im Blick behalten.

Prüfschritte:

• Zuerst sollten wir sicherstellen, dass der Verifier wie vorgesehen nach magicBytes sucht. Wenn nötig, sollte er das factory-Deployment simulieren und erst danach die ERC-1271-Prüfung durchführen.
• Um uns gegen Cross-Network-Replay abzusichern (wenn der gleiche Factory-Bytecode/Calldata auf einer anderen Chain genutzt wird), müssen die dApp-Server die Domain und die ChainId unbedingt strikt verknüpfen.
• Für den Tooling-Test: Lass uns den Off-Chain-Verifier (zum Beispiel WalletConnect oder das reown erc6492 crate) mit unseren eigenen Backends testen. Du kannst dir dazu mehr Infos hier holen: eips.ethereum.org.

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

Ziele:

• Wir wollen sicherstellen, dass eine EOA‑Signatur nicht mehrmals in verschiedenen eigenen Smart‑Accounts verwendet wird.

Prüfschritte:

• Lass uns die Nested‑Typed‑Signatures nach ERC‑7739 testen. Dabei machen wir ein defensives Re‑Hashing, das auch die Account‑Adresse einbezieht.
• Fuzz-Test: Wir validieren die Signatur für Account X gegen Account Y - das muss fehlschlagen. (ercs.ethereum.org)

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

Ziele:

• Die Delegation ist nur im Sender-Kontext erlaubt. Die Gas-Schätzung berücksichtigt dabei zusätzliche Kosten, und die Widerrufung ist sauber umgesetzt.

Prüfschritte:

• Die AUTH-Regeln aus 7562: EIP-7702-delegierte Accounts dürfen im UserOp nur als Sender auftreten. Außerdem müssen die Mehrfach-Authorisierungen konsistent sein.
• Der preVerificationGas umfasst 25.000 anfallende Zusatzkosten (sofern zutreffend). (eips.ethereum.org)

---

Testkatalog B: UserOperations, Bundler & Mempool

B1) EntryPoint‑Kompatibilität und Versionserkennung

Ziele:

• Die Wallet/SDK soll automatisch zwischen v0.6 und v0.7 wählen, abhängig vom validateUserOp-Parameter (UserOperation vs PackedUserOperation).

Prüfschritte:

• On-Chain ABI-Check, Adressverifikation (für v0.7: 0x000000007172…032), Simulation gegen beide Varianten und ein Migrationspfad-Smoketest. (alchemy.com)

B2) UserOperation‑Hashing & Packing

Ziele:

• Sicherstellen, dass keine Diskrepanzen zwischen der Off-Chain-Signatur und der On-Chain-Validierung auftreten; bugs beim Packing/Offset sind ein No-Go.

Prüfsteps:

• Wir führen Differential-Tests mit verschiedenen Signern/SDKs gegen EntryPoint.getUserOpHash durch und machen Mutationstests an initCode/callData.
• Zur Regression: Wir checken die alten Calldata-Packing-Schwachstellen aus 2023 - wichtig, dass die Fixes aktiv sind und wir die nötigen Tests haben. (alchemy.com)

B3) ERC‑7562‑Regeln & DoS‑Resilienz

Ziele:

• Die Validierungsphase ist klar strukturiert, hat begrenzte Ressourcen und funktioniert isoliert; hier kommen Reputation und Throttling ins Spiel.

Prüfsschritte:

• Trace-Simulations-Suite: Hier schauen wir uns den Banned/Throttled-Pfad an, prüfen die MAX_USEROP_SIZE/CONTEXT-Größen, die Einhaltung des Gas-Slack und die verbotenen Opcodes.
• P2P-Propagations-Tests: Wir testen mit einem Shared-Mempool und isolierten Bundlern; dabei validieren wir den Drop-/Retry-Pfad. Mehr dazu hier.

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

Ziele:

• Einheitliche Fehlercodes/Debug‑RPCs; Wallets/SDKs sollen gegen mehrere Bundler austauschbar sein.

Prüfsteps:

• Conformance‑Suite für eth_sendUserOperation + Debug‑RPC; Fuzzing mit ungültigen Feldern/Nonces; Protokollierung der Ablehnungsgründe. (eips.ethereum.org)

---

Testkatalog C: Paymaster, Gebühren & Abrechnung

C1) Stake/Deposit‑Pfad & Sicherheitslogik

Ziele:

• Der Paymaster ist gestaked und hat genug Deposit; die Zeiten für Withdraw/Unstake sind korrekt; Risiken durch Griefing sind minimiert.

Prüfsschritte:

• EntryPoint: getDepositInfo, balanceOf, depositTo, addStake und withdrawStake werden in Rundlauf-Tests überprüft; es gibt Reverts bei Unterdeckung.
• Letzte Tests mit fehlerhaften Operationen → Der Paymaster zahlt wie erwartet; die PostOp-Abrechnung ist robust. (eips.exposed)

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

Ziele:

• Stellt sicher, dass die Gaslimits für die Paymaster‑Validierung/PostOp richtig gesetzt sind; die Bundler‑Schätzung bleibt konsistent.

Prüfschritte:

• Überprüfe den Signatur-/Stub‑Fluss durch pm_getPaymasterStubData/pm_getPaymasterData (ERC‑7677). Achte darauf, die EntryPoint‑Version zu erkennen und die Felder entsprechend auszufü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:

• Alles, was das Modul-Installieren/Deinstallieren, Hook-Kaskaden, Fallback-Handler und Executor/Validator-Wege betrifft, sollte schön standardkonform und durch die Registry geprüft sein.

Prüfschritte:

• Zuerst schauen wir uns die Modul-Bestätigung über den Registry-Adapter (ERC-7484) an, dann blockieren wir unsignierte oder nicht attestierte Module und evaluieren die Zeit-Lock sowie Resource-Lock Policies. (eips.ethereum.org)

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

Ziele:

• Temporäre Schlüssel mit Policies (wie Zeitfenster, Ziel‑Whitelist und Limits) sollen über Konten und Chains hinweg einheitlich funktionieren.

Prüfschritte:

• Nutze das Session‑Manager‑Modul (wie zum Beispiel SmartSession); setze die Mehrketten‑Policy‑Durchsetzung um; führe explizite Revoke- und Expiry-Tests durch. Weitere Infos findest du hier: rhinestone.dev.

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

Ziele:

• P‑256‑Verifikation ist on-chain vorhanden (RIP/EIP‑7212 Precompile, Address/Cost) und muss korrekt in validateUserOp eingebaut werden.

Prüfsschritte:

• Zuerst die Chain‑Capabilities herausfinden; falls die Precompile fehlt, auf einen Software‑Verifier zurückgreifen. Dabei die Gas‑Kosten im preVerificationGas nicht vergessen.
• Schließlich die End‑to‑End‑Flows mit der WebAuthn‑API signieren und on‑chain überprüfen. Weitere Infos dazu gibt's hier: (eip.info).

---

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

Ziele:

• UserOps sollen zuverlässig mit den (Shared) Alt‑Mempool‑Peers verbunden werden; wir wollen keinen festgelegten Single‑Bundler‑Lock-in; optional soll es eine Private‑Submission für sensible Flows geben.

Prüfschritte:

• Mehrere Bundler gleichzeitig ansprechen; die Präsenz im Shared‑Mempool überprüfen; die Status‑Konsistenz über RPCs sicherstellen.
• Für vertrauliche Aktionen testen wir experimentell private oder verschlüsselte Pfade und halten dabei die Grenzen in 4337 im Hinterkopf. Schaut euch auch die detaillierten Infos hier an.

---

Praxisnahe Beispiel‑Szenarien (mit konkreten Checks)

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

• Flow: Die dApp fragt nach dem Sign-In; falls der Smart-Account noch nicht bereitgestellt ist, nutzen wir den 6492-Wrapper und factoryCalldata.
• Checks:
  • Der Server überprüft zuerst die magicBytes, simuliert dann den factory-Deploy und ruft danach isValidSignature auf.
  • Zum Schutz vor Replay-Angriffen: Die EIP-712-Domain beinhaltet chainId und verifyingContract; Cross-Chain-Versuche werden blockiert. (eips.ethereum.org)

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

• Flow: Der EOA signiert die Autorisierung, und die Wallet führt den Batch über wallet_sendCalls (EIP‑5792) mit der Paymaster‑Funktionalität aus.
• Checks:
  • Der preVerificationGas umfasst die Autorisierungskosten von 7702; die AUTH‑Regeln aus 7562 sind eingehalten.
  • EIP‑5792: Die Wallet gibt die paymasterService‑Funktion an; die App übermittelt die URL/den Kontext → pm_getPaymasterData liefert die richtigen Felder für v0.6/v0.7. (eip.info)

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

• Flow: So, we're talking about the WebAuthn Signature (P-256) here. The validateUserOp function does its thing by checking the p256 (this can be done via Precompile or using a Solidity Verifier), and just a heads up, the Session Key is capped at 24 hours.
• Checks:
  • The chain totally supports RIP/EIP-7212 (you can find it in Precompile 0x0100, and you’re looking at typical verification costs around ~3,450 Gas).
  • Session Key Policy: This includes a target whitelist, a spending cap, and an expiration setup; plus, there's a revoke path. For more details, check out ritualfoundation.org.

Beispiel 4: Paymaster‑gesponserte Free‑Trial‑Aktionen

• Flow: dApp sponsert die ersten Aktionen; PM-Stub-Daten zur Gas-Schätzung; final pm_getPaymasterData signiert.
• Checks:
  • Genügend Deposit/Stake vorhanden; Revert-Kosten werden vom Paymaster übernommen und richtig verbucht.
  • v0.7-Felder paymasterVerificationGasLimit/paymasterPostOpGasLimit sind korrekt gesetzt. (eips.ethereum.org)

---

Metriken & Beweisführung für Management‑Reports

• Signatur-Robustheit
  • Hier geht's um den Anteil der abgewiesenen Kollisionstests, speziell bei 712-Domain-Mismatches und 7739-Replay-Versuchen.
• UserOp-Reliabilität
  • Das sind die Simulations-Erfolgsquoten, die First-Inclusion-Raten und die Gründe für Ablehnungen (wenn wir über 7769-konforme Fehlercodes sprechen). Weitere Infos dazu findest du hier.
• Mempool-Gesundheit
  • Wir vergleichen die Shared-Mempool-Propagation mit einem Single-Bundler und schauen uns die Drop-/Retry-Quoten unter den 7562-Regeln an. Mehr Details dazu gibt's hier.
• Paymaster-Risikokennzahlen
  • Das umfasst den Gasverbrauch pro gesponserter Aktion, die Revert-Quote sowie die Deposit-Coverage in Blöcken, speziell im Worst-Case-Szenario.
• Modul-Compliance
  • Hier sehen wir uns den Anteil der installierten Module an, die gültige ERC-7484-Attestationen haben, und die Mean-Time-to-Revoke.

---

Tooling & Automatisierung (schnell integrierbar)

• Fuzz-Testing und Conformance-Testing von Bundler/Paymaster/Accounts mit permissionless.js (vendor-agnostisch und viem-basiert).
• Nutzung von 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 testen. (eips.ethereum.org)

---

„Best Emerging Practices“ für 2025‑Rollouts

• Signaturen
  • Setz immer auf ERC‑5267; frag die Domain direkt in den Backends live ab, anstatt das statisch zu konfigurieren. (eips.ethereum.org)
  • Erzwänge den Low‑S‑Check in deinen Verträgen; nutz 712‑Signaturen mit kompletter Domain (inklusive chainId & verifyingContract). (eips.ethereum.org)
  • Für Counterfactual‑Flows ist es wichtig, den 6492 konsequent zu nutzen und Cross‑Chain‑Replays ausdrücklich zu blockieren. (eips.ethereum.org)
• UserOps
  • Zieh EntryPoint v0.7 vor; plane ein Migrationsfenster mit Dual‑Support (v0.6/v0.7). (outposts.io)
  • Mach 7562‑Konformität zu einem CI‑Gate (mit Opcode‑Verbote, Größenlimits und Reputations‑Triggern). (eips.ethereum.org)
  • Nutze 7769‑RPC für portable Wallet/Bundler‑Tests; standardisiere die Ablehnungs‑Telemetry. (eips.ethereum.org)
• Paymaster
  • Integriere ERC‑7677; nutze Stub‑Daten für präzise Gas‑Schätzungen; schätze und setze PostOp‑Kosten selbst durch den Paymaster (v0.7). (eips.ethereum.org)
  • Überwache Deposits/Stake mit automatischen Top‑ups; setze Policies gegen „sponsored griefing“. (docs.erc4337.io)
• Modularität
  • Setz ERC‑7579 als Mindeststandard; akzeptiere nur Module mit 7484‑Attestationen. Stelle sicher, dass Session‑Keys klare Policy‑Bundles (Limit/Scope/Expiry) haben. (eips.ethereum.org)
• Passkeys
  • Wo verfügbar, nutze RIP/EIP‑7212 (test Gas/Kompabilität); falls nicht möglich, setz auf geprüfte On‑Chain‑Verifier. (eip.info)

---

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

• Vorab
  • Zuerst mal, wir sollten uns über den Threat-Model für verschiedene Use-Cases wie Login, Zahlung und Automatisierungen Gedanken machen.
  • Außerdem müssen wir die Chain-Fähigkeiten (7702/7212/EntryPoint-Version) im Blick behalten. (alchemy.com)
• Signaturen
  • Lass uns die ERC‑1271/5267/712/6492/7739‑Testsuite durchgehen, um sicherzustellen, dass alles läuft (Replay, Domain-Mismatch, Counterfactual, Low-S). (eips.ethereum.org)
• UserOps
  • Hier schauen wir uns die getUserOpHash-Vergleiche an und prüfen die 7562-Konformität sowie die 7769-RPC-Interop. Und ja, wir sollten auch die Mehr-Bundler-Einreichung berücksichtigen. (eips.ethereum.org)
• Paymaster
  • Für den Paymaster-Bereich müssen wir das Stake/Deposit-Round-Trip im Auge behalten, ebenso wie die v0.7-Gasfelder, 7677-Stubs/Data und den Revert-Kostenschutz. (hackmd.io)
• Modularität
  • Bei der Modularität sollten wir die 7579-Interfaces, Hook-Kaskaden, Registry-Attestationen (7484) und die Session-Key-Revocation nicht vergessen. (eips.ethereum.org)
• Passkeys
  • Schließlich, ist die 7212-Precompile schon am Start? Lass uns das WebAuthn-End-to-End anschauen und überprüfen, ob wir das preVerificationGas anpassen müssen. (ritualfoundation.org)

---

Fazit

Für Entscheider gibt's keine zwei Meinungen: Smart-Account-Sicherheit hängt längst nicht mehr nur von der Kryptografie ab. Es geht um End-to-End-Pfade - also Themen wie Domain-Trennung, modulare Validierung, Mempool-Verhalten und Kostenkontrollen. Wenn du 2025 mit einem Produkt richtig durchstarten möchtest, dann solltest du auf 7562-konforme Simulationen, 7769-RPC-Interop-Tests, 7579/7484-Modul-Governance und 7212-fähige Passkey-Flows setzen. Und nicht zu vergessen: Paymaster-Sponsoring mit 7677-Kompatibilität. So wird aus einer Wallet-UX ein echtes, belastbares Unternehmenssystem. (eips.ethereum.org)

---