fix(security): use CSPRNG for approval card ids + clicker authorization

[smith-vosburg]

Type of Change

• Fix - bug fix or security fix to source code

Description

Two related security fixes to the approval-card flow.

1. Replace Math.random() approval ids with crypto.randomBytes()

shortApprovalId() in src/modules/approvals/onecli-approvals.ts currently does:

Math.random().toString(36).slice(2, 10)  // ~41 bits of entropy

This id is the secret for click approvals. The Chat SDK's Telegram adapter uses it directly as callback_data actionId, and resolveOneCLIApproval() dispatches the registered approval handler when a click arrives carrying that id. There is no second-factor auth on the click path beyond knowing the id, so anyone who can submit a callback with a guessed id can approve a credentialed action they shouldn't.

~41 bits of Math.random() entropy (which is not a CSPRNG to begin with — V8's Math.random is xorshift128+) is well within brute-force range against the pool of pending approvals.

Fix: randomBytes(16).toString('base64url') → 128 bits of CSPRNG entropy. The encoded id is 22 chars, comfortably under Telegram's 64-byte callback_data budget after the oa- prefix and the Chat SDK callback wrapper.

2. Add a clicker-authorization check in the approval response handler

Independently of the id-guessing risk, the response handler in src/modules/approvals/response-handler.ts did not verify that the clicker is one of the eligible approvers for the approval's agent group. Without this check, a forged click — including one that spoofs another user's id via payload.userId — would dispatch the approval handler.

Fix: new isAuthorizedClicker() runs pickApprover(session.agent_group_id).includes(clickerId) (where clickerId = ${channelType}:${userId}) before invoking the handler. Mirrors the existing handleSenderApprovalResponse check in src/modules/permissions/. Unauthorized clicks are claimed (so the dispatcher doesn't retry) but no other action is taken; the pending row stays so a real approver can still resolve it.

Threat model

The id-IS-secret property means either of these alone is exploitable:

• An attacker who can enumerate/guess pending approval ids (~41 bits) and forge a click → approval handler fires.
• An attacker who can submit a click with a known pending id but a spoofed userId → approval handler fires (no auth check).

Both fixes are needed for defense-in-depth: CSPRNG ids make the first attack infeasible; clicker auth makes the second attack ineffective even if an id leaks (e.g. via logs, screen-share, debug output).

Tests

• src/modules/approvals/onecli-approvals.test.ts (new) — id format + entropy properties
• src/modules/approvals/response-handler.test.ts (new) — auth-gate end-to-end behavior

Test Files  2 passed (2)
     Tests  7 passed (7)

pnpm typecheck is clean. Lint only reports pre-existing no-catch-all warnings on the touched files (not introduced by this PR).

Notes

• Cherry-picked from vosburg-auto/nanoclaw@ad4d5f5. The original commit also bundled a src/webhook-server.test.ts for a resolveListenConfig export that doesn't exist on this repo's main — that test was dropped from this PR. If you want the companion change (default webhook bind to 127.0.0.1 instead of the current 0.0.0.0 LAN-exposed bind in src/webhook-server.ts:121), happy to open a separate PR.
• Authored by ark234 (commit author preserved through the cherry-pick); pushed via the smith-vosburg machine identity from the same operator.

🤖 Generated with Claude Code