harden: remembered site permissions are keyed by hostname only, dropping the scheme and port #402

New Issue

2026-09-21T20:37:56+02:00

clawbot commented

2026-09-21 20:37:56 +02:00

Severity: hardening.

Where. src/background/index.js:259-265 (extractHostname), 621-640
(handleConnectionRequest checks allowedSites/deniedSites by hostname) and
1097-1102 (accountsChanged uses the same hostname match). Remembered
permissions live in state.allowedSites / deniedSites keyed by hostname;
in-memory session connections are keyed by full origin.

What is wrong. A permission granted to https://dapp.example is honoured for
http://dapp.example and for any port on that host, because only the hostname is
stored and compared. The approval and signing prompts display the hostname only,
so the user cannot see the scheme.

Why it matters. A network attacker who can serve a cleartext page for a host
the user has connected to over https inherits the connection and can raise
signing prompts under the trusted name.

Reproduction. Connect to https://dapp.example with Remember; later load
http://dapp.example (for example via a network attacker); eth_accounts
returns the address with no prompt, and eth_sendTransaction opens a prompt
naming dapp.example.

Acceptable. Key remembered permissions by full origin (scheme://host[:port])
and show the origin (at least the scheme) on all three prompts; migrate existing
hostname entries.

Definition of done.

Remembered permissions are stored and matched by full origin.
The connection, transaction and signature prompts display the origin, not
the bare hostname.
Existing hostname-keyed entries are migrated (for example treated as https
origins) so no grant is lost silently.
A test asserts an https grant does not authorise the http origin of the
same host.

Model: fable-5-1 (review); opus-4-8 (filing)

Severity: hardening. **Where.** `src/background/index.js:259-265` (`extractHostname`), `621-640` (`handleConnectionRequest` checks `allowedSites`/`deniedSites` by hostname) and `1097-1102` (`accountsChanged` uses the same hostname match). Remembered permissions live in `state.allowedSites` / `deniedSites` keyed by hostname; in-memory session connections are keyed by full origin. **What is wrong.** A permission granted to `https://dapp.example` is honoured for `http://dapp.example` and for any port on that host, because only the hostname is stored and compared. The approval and signing prompts display the hostname only, so the user cannot see the scheme. **Why it matters.** A network attacker who can serve a cleartext page for a host the user has connected to over https inherits the connection and can raise signing prompts under the trusted name. **Reproduction.** Connect to `https://dapp.example` with Remember; later load `http://dapp.example` (for example via a network attacker); `eth_accounts` returns the address with no prompt, and `eth_sendTransaction` opens a prompt naming `dapp.example`. **Acceptable.** Key remembered permissions by full origin (`scheme://host[:port]`) and show the origin (at least the scheme) on all three prompts; migrate existing hostname entries. **Definition of done.** - [ ] Remembered permissions are stored and matched by full origin. - [ ] The connection, transaction and signature prompts display the origin, not the bare hostname. - [ ] Existing hostname-keyed entries are migrated (for example treated as https origins) so no grant is lost silently. - [ ] A test asserts an https grant does not authorise the http origin of the same host. Model: fable-5-1 (review); opus-4-8 (filing)

clawbot referenced this issue

2026-09-21 20:39:01 +02:00

security: pre-1.0 review of key handling, DEBUG mode and RPC/dApp input validation #383

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#402