Skip to content

Harden website access, wallet authorization, and transaction confirmation - #1561

Open
KillariDev wants to merge 5 commits into
mainfrom
t3code/security-audit
Open

Harden website access, wallet authorization, and transaction confirmation#1561
KillariDev wants to merge 5 commits into
mainfrom
t3code/security-audit

Conversation

@KillariDev

@KillariDev KillariDev commented Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Summary

This PR closes trust-boundary gaps across website permissions, wallet signing, and transaction forwarding so the origin, account, and transaction approved by the user are the ones the extension ultimately authorizes and sends.

  • Make website permissions exact-origin aware, including scheme, host, and explicit non-default port.
  • Migrate legacy host-only access records without silently broadening authorization.
  • Preserve restrictive legacy decisions such as site denials, address denials, disabled-provider state, and request blocking.
  • Bind account access and signing requests to the actively authorized wallet account.
  • Use one validated transaction representation for simulation, confirmation, and wallet forwarding.
  • Require explicit acknowledgement before forwarding quarantined signing requests.
  • Reject unsupported or inconsistent transaction forms instead of silently changing them.
  • Add regression coverage for access precedence, migration, account changes, transaction equivalence, Safe flows, EIP-7702 authorization data, and quarantine enforcement.

Secure interception and simulation for wallet_sendCalls remains tracked separately in #1560.

Why

Previously, several values could change or become ambiguous after the user made a security-sensitive decision:

  • Host-only access records could not distinguish HTTP from HTTPS or represent an exact port.
  • A pending request could outlive the account authorization under which it was created.
  • The transaction reviewed or simulated could diverge from the payload sent to the wallet.
  • Unsupported fields could be normalized away rather than rejected.
  • Quarantined signing requests did not always require a final explicit acknowledgement.

This PR makes those boundaries explicit and fails closed when a request cannot be preserved faithfully.

Website access and migration

  • Store, compare, and display canonical website origins.
  • Keep legacy positive grants pending until the exact current origin is approved.
  • Continue enforcing legacy restrictive decisions during migration.
  • Allow an exact-origin address decision to override only its matching legacy address decision.
  • Drop malformed and credential-bearing stored URLs.
  • Preserve explicit ports in Manifest V3 content-script match patterns.
  • Export the scheme-aware settings format as version 1.5 while continuing to import versions 1.0 through 1.5.

Wallet and signing authorization

  • Cache the account associated with an approved page connection and validate it throughout the request lifecycle.
  • Prevent pending requests from being revived by authorizing a different account later.
  • Require signing targets to match the currently authorized account.
  • Require explicit user acknowledgement for quarantined signing requests.

Transaction confirmation

  • Canonicalize and validate transaction fields once, then reuse that representation through simulation, review, and forwarding.
  • Bind sender, chain, nonce, access list, fee model, transaction type, and EIP-7702 authorization data across the full flow.
  • Reject sender or chain mismatches, incompatible type/field combinations, and unsupported EIP-4844 blob transactions.
  • Keep Safe confirmation metadata and signer routing aligned with the validated request.

Compatibility

Existing state is preserved wherever it can be interpreted without weakening security:

  • Older settings and address-book exports remain importable.
  • Existing denials and request-blocking rules remain effective.
  • Legacy positive host-only grants require a one-time exact-origin approval.
  • Supported transaction and signing requests continue to work when their account, chain, type, and fields are internally consistent.

Older releases do not understand the new v1.5 export format, and requests that depended on mismatched or discarded fields now fail closed by design.

Validation

  • bun run test — 1,232 passed, 0 failed.
  • bun run setup-chrome — passed.
  • bun run typecheck — passed.
  • bun run lint — passed.
  • bun run test:chrome-communication — passed against the built Manifest V3 extension.
  • git diff --check — passed.

@KillariDev
Harden wallet approval and transaction confirmation flows
73b7f98
@KillariDev
Preserve legacy website access safely
8b1d618
@KillariDev
Preserve restrictive legacy access decisions
479ad6c
@KillariDev
Merge remote-tracking branch 'origin/main' into t3code/security-audit
d54f37d 
# Conflicts:
#	app/ts/background/accessManagement.ts
#	app/ts/background/popupMessageHandlers.ts
#	app/ts/background/providerMessageHandlers.ts
#	app/ts/background/settings.ts
#	app/ts/background/windows/confirmTransaction.ts
#	app/ts/types/JsonRpc-types.ts
#	app/ts/utils/contentScriptsUpdating.ts
#	test/tests/backgroundEthAccounts.test.ts
#	test/tests/contentScriptsUpdating.test.ts
#	test/tests/terminalReplyDelivery.suite.ts
@KillariDev KillariDev changed the title Harden wallet authorization and transaction confirmation Harden website access, wallet authorization, and transaction confirmation Aug 14, 2026
@KillariDev
Fix popup listener cleanup and Safe confirmation test inputs
a009b01 
- Remove listeners using callbacks from the previously opened dialog
- Include quarantine acceptance in Safe confirmation scenarios

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@KillariDev