A store's own page can make the node land attacker-chosen capsules bondable — same-origin survives the two-axis fold

[MichaelTaylor3d]

Task

A store's own page, served by the node at /s/<store>/, can make the node land attacker-chosen capsules as bondable — and it survives the two-axis fold that fixes the cross-site case (dig-node#436, PR #442).

This is not the cross-site variant. That one is fixed: chrome-extension:// and cross-site pages now fold to Peer and land Suppress. This is the same-origin variant, and it is more reachable, because the node's own CSP explicitly permits it.

The chain, each link verified in the tree

1. /s/*path and POST / are the SAME router on the SAME port — server.rs:255 (.route("/", get(health).post(rpc))) and server.rs:281 (.route("/s/*path", get(store_serve))), one Router::new() at :254, served on all three listeners at :2290/:2298/:2306.
2. A store page therefore shares an origin with the RPC endpoint. http://dig.local:<port>/s/<store>/index.html and http://dig.local:<port>/ differ only in path.
3. The CSP permits the attacker's script to run and to call back. STORE_CSP (content.rs:96-104) sets script-src 'self' 'unsafe-inline' 'unsafe-eval' blob: and connect-src 'self' …. 'self' IS the RPC endpoint.
4. The browser reports Sec-Fetch-Site: same-origin → RequestProvenance::FirstParty (download.rs:397 maps only "cross-site" to CrossSite; :5287 records that an absent or unknown value defaults to first-party).
5. landing_origin(Local, FirstParty) == Local (download.rs:412-417) → holder_claim_for_read returns Announce → the capsule lands unmarked → Held → bondable.

The attacker chooses the store_id/root in the request, so they choose what this operator stakes $DIG on. And because Announce removes an existing marker (module_reshare.rs:337-341), the same call can un-suppress a capsule that was correctly relayed.

Trigger: anyone views the attacker's store in a browser. Publishing a store is permissionless, and viewing one is the product's core action.

Why the two-axis model cannot express the fix

Both the operator's own UI and attacker content served at /s/ are (Local, FirstParty). The axes are transport and cross-site-ness; neither carries "this request was authored by content the node is hosting for a stranger". Same-origin stopped being a trust signal the moment the node began serving untrusted content on its control origin.

That is a shape question, not a patch — settle it before building (§1.10):

• Separate the origins. Serve /s/* from a distinct port or subdomain so store content is never same-origin with the control plane. Cleanest, and it fixes the whole class rather than this symptom; costs a URL change and whatever depends on store_base_href / reroot_via_referer.
• Derive a third provenance from Referer/Origin. A request whose referer is a /s/<store>/ path is never FirstParty for landing. Cheaper, but leans on a header and needs the absent-header default to fail closed here while it fails open elsewhere (download.rs:5287).
• Tighten connect-src. Dropping 'self' from STORE_CSP blocks the callback, but breaks any store that legitimately talks to the node — check whether any does before assuming this is free.

Scope

Deliverable is the assessment plus the chosen fix. Do not widen into a general /s/ sandboxing epic.

connect-src 'self' also lets a store page reach every other open RPC method, not just dig.getContent. Landing/bondability is what this ticket is about; whether the broader surface is a separate defect wants a look, and should be a sibling if so.

Evidence

Traced link-by-link in the tree at a1894e78. Not fired — no exploit was executed against a running node. Everything above is a code read, and step 4 in particular is a claim about browser behaviour that a live check would settle in minutes.

Acceptance

A page served at /s/<store>/ cannot cause a capsule to land Held. Proven by a test asserting that a read attributable to store-served content backfills Suppress, and — per the lesson this family keeps teaching — the test must fail if the decision reverts. Both existing holder_claim_tests passed with the single-axis bug present; a test below the decision is not evidence about the decision.

[MichaelTaylor3d]

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166 (closed — the mirror lifecycle it protects is proven on mainnet)
Sibling: #436 (the cross-site half, fixed in PR #442)
Related: #446 (inbound-demand backfill provenance)

Found while verifying a security gate's own finding rather than accepting it. The gate correctly identified that holder_claim_for_read read one axis; the fold it prescribed is right and has landed. Checking whether the fold actually closed the path — instead of assuming a correct-looking fix closes what it addresses — surfaced this variant, which the fold does not reach and which the node's CSP explicitly enables.

[MichaelTaylor3d]

Lane loop/batch-cache, draft PR #455, head 278c4c0.

Shape decision: option 2, but derived from Sec-Fetch-Site alone — NOT from Referer.

A third provenance, RequestProvenance::StoreServed, folding to Peer in landing_origin.

Why not the ticket's three options as written:

• Separate the origins fixes the class and is the right long-term shape, but it is a URL change with cross-repo consumers (store_base_href, reroot_via_referer, dig-app, the extension). Too wide for the live exploit.
• Referer-derived is bypassable by the exact party it constrains: a store page sets its own referrer-policy and can reduce Referer to origin-only (stripping the /s/<store> path) or remove it entirely. Either makes the request look non-store and lands. So a Referer rule fails open to a one-line <meta> tag.
• Tighten connect-src is insufficient, not merely costly. img-src 'self' alone lets a page issue GET /s/<other-store>/big and land it; CSP cannot express a per-path distinction, and removing 'self' from every fetching directive breaks stores loading their own assets.

What the fix rests on instead: /s/* is the ONLY HTML surface this router serves — /, /health, /version, /openrpc.json, /.well-known/*, /ws, /ws/status, /verify/* are all non-HTML (server.rs:255-285). So a page-driven request arriving on this origin was, by construction, authored by store content. Sec-Fetch-Site is browser-set and a forbidden header name, so page script can neither forge nor strip it.

Sec-Fetch-Site	provenance	lands?
absent	FirstParty	yes — non-browser CLI/SDK, unchanged
none	FirstParty	yes — user-initiated top-level nav; script can never produce this value
same-origin / same-site / unknown	StoreServed	no — folds to Peer
cross-site	CrossSite	no — unchanged

The flywheel survives. The top-level navigation that opens a store is none, so it still lands the capsule; every subresource is then served from that already-landed capsule. The cost is narrow and stated: a subresource no longer lands on its own.

Unknown values now fail CLOSED (previously open). The read is never blocked either way.

Tests, and what each catches:

• sec_fetch_site_page_driven_values_are_store_served — the mapping.
• sec_fetch_site_none_is_first_party_so_the_operator_still_lands_a_store_they_opened — the truthful control; catches an over-broad fold that would silently kill browser-initiated landing.
• sec_fetch_site_unknown_value_fails_closed_to_store_served — the inverted default.
• sec_fetch_site_is_case_insensitive_and_trims — extended with a page-driven case.
• a_store_served_read_over_a_local_socket_backfills_suppressed (dispatch) — the DECISION, over a Local transport, which is the input that distinguishes the fix from doing nothing.
• a_store_served_request_never_lands_however_local_its_transport_is (download) — the fold, with a FirstParty/Local control on the same axis.
• store_serve_labels_provenance_from_sec_fetch_site_without_blocking_the_read (integration) — updated to same-origin → StoreServed, plus a new none → FirstParty control.

Revert-proofs (committed first, reverted by file copy):

• Reverting the mapping only: 3 of 6 FAILED, 3 passed.
• Reverting the fold only (StoreServed => origin): the new dispatch test FAILED while all four pre-existing holder_claim_tests passed — confirming, as the ticket predicted, that the Prove every remote-triggered cache-fill marks Relayed — with a broadcaster wired, a mis-provenance becomes a real spend #436 tests are green with the A store's own page can make the node land attacker-chosen capsules bondable — same-origin survives the two-axis fold #450 bug present.

Unverified: step 4 of the chain (that a browser actually reports same-origin here) is still a code-read claim; I have not fired it against a running node. The fix is strictly safer than the status quo under either answer, since it only ever restricts landing.

Sibling not opened yet: connect-src 'self' also exposes every other open RPC method to store pages. Out of scope here per the ticket; flagging it rather than widening.