[Bug 报告] LAN 部署下审批可被旁路：/api/respond 不在 loopback 钉扎名单，局域网设备可批准工具调用/回答问题

[truelove-dreamer]

建议分类：Bug report（安全）
环境：@deepseek-ai/dsh 0.1.0-rc.6，仅在显式配置 LAN 访问时受影响（--trusted-host 或自定义 host: 0.0.0.0 配置）；默认 127.0.0.1 部署不受影响
严重级别：major——审批是"用户同意"这一安全控制，LAN 上可被完全绕过

摘要

Web 部署的 /api 面有一份"钉扎到 loopback"的特权方法名单 PRIVILEGED_METHODS（dsh-client-connection/lib/index.js:504-520，含 settings/credentials 等敏感方法）。但审批应答方法 respond 不在名单里。一旦用户通过 --trusted-host <LAN-IP> 让 LAN 设备可以访问 Web（这是官方支持的用法），任何局域网设备都可以：

1. 订阅服务端→浏览器的 mux 事件流（/api/events.mux），被动拿到 approval/requested 帧（内含 rpcId / approvalId / sessionId）；
2. 向 /api/respond POST 一个伪造的应答包，把 outcome 置为 "allowed-once"；
3. 结果：替用户批准任意待审批的工具调用（如提升权限的 shell 命令）、或代替用户回答 ask_user_question。

配套问题：Typert 网关以 authority: "trusted-host" 注册拦截器（dsh-api-gateway/lib/index.js:62），绕开 PRIVILEGED_METHODS 的 loopback 复检（dsh-client-connection/lib/index.js:232-240 只在 loopback 时用空信任列表）——两套调度平面的安全策略不一致；0.0.0.0 绑定还会把全部 LAN IPv4 自动加入信任列表（dsh-web-app/lib/index.js:47-53）。代码注释自己也声明 trustedHosts "explicitly not authentication"。

证据（代码与行号）

• 钉扎名单不含 respond：dsh-client-connection/lib/index.js:504-520（PRIVILEGED_METHODS 集合成员列表）；
• respond 只校验 rpcId/approvalId/sessionId 匹配，无来源校验：dsh-host-apiproxy/lib/index.js:3816-3865（respond(message) → pendingApprovals.get(message.rpcId) → 校验 parsed.data.approvalId !== approval.approvalId || parsed.data.sessionId !== approval.sessionId → approval.resolve(parsed.data.outcome)；问题同理 :3831-3864）；
• 审批请求帧经 mux 流广播给浏览器：dsh-host-apiproxy/lib/index.js:1350-1361（requestedFrame 携带 rpcId/sessionId/approvalId）；
• mux 升级路径的栅栏对 trustedHosts 放行：dsh-client-connection/lib/index.js:569-573（isTrustedApiRequest，Host=LAN IP 字面量命中 trustedHosts 即通过）；
• 应答包 schema：dsh-host-apiproxy/lib/types/api/approvals.schema.js:11-15（{sessionId, approvalId, outcome: "allowed-once" | "rejected"}）；问题应答 dsh-host-apiproxy/lib/types/api/questions.schema.js:17+。

复现步骤（概念验证）

前置：dsh --profile web --trusted-host 192.168.1.100（或自定义 cordis.yml 配 host: 0.0.0.0），使 LAN 上其他设备能访问 http://192.168.1.100:3080/。

1. 触发一个待审批操作：在任一 Web 会话里让 agent 发起一个触发审批的工具调用（或 ask_user_question）；
2. 从另一台 LAN 机器打开 WebSocket 连 ws://192.168.1.100:3080/api/events.mux（浏览器形态请求，Host 头为 LAN IP 字面量 → 通过栅栏），等待并记录 approval/requested 帧中的 rpcId、approvalId、sessionId；
3. POST 伪造应答到 /api/respond（respond 的 wire 形态为 client-response 信封）：

   {
     "type": "client-response",
     "rpcId": "<步骤2捕获的 rpcId>",
     "result": {
       "ok": true,
       "value": {
         "sessionId": "<步骤2捕获>",
         "approvalId": "<步骤2捕获>",
         "outcome": "allowed-once"
       }
     }
   }

4. 观察：agent 的待审批工具调用被执行；用户本人从未点过"允许"。

影响

• 审批这一安全控制在 LAN 部署下完全失效：设备无需任何凭据即可批准任意工具调用（含可能提升为完整 shell 权限的 escalation 请求）、或替用户回答提问；
• ask_user_question 的答案也可被伪造，模型会把它当作真人输入执行后续动作；
• 即便不配 --trusted-host，若自定义配置把 webserver 绑到 0.0.0.0，resolveLanTrust 会把所有非内网 IPv4 自动加入信任列表，问题面进一步扩大。

建议修复（供讨论）

1. 最小修复：把 respond（以及 session.export 等无认证副作用端点）纳入 PRIVILEGED_METHODS，钉扎到 loopback；
2. 让 Typert 网关拦截器与 fetch 网桥共用同一套 PRIVILEGED_METHODS 门禁（或在 gateway 层单独复检）；
3. webserver Config schema 与 CLI 保持一致拒绝 0.0.0.0，或在 0.0.0.0 时强制要求显式 --trusted-host 并输出警告；
4. 长期：在真正认证层出现前，所有跨 loopback 的"影响宿主/批准操作"都应默认拒绝。

附注

• 已确认非问题：默认（127.0.0.1）部署下该链不可达；DNS rebinding 栅栏主链路（isTrustedApiRequest）本身逻辑正确；
• 本报告的定位是"trustedHosts 被明确标记为非认证，但 respond 这类高影响方法却没有像 settings/credentials 一样钉扎 loopback"——两处设计意图不一致。