Repository navigation
[SEC][CODE] renderer 可裸 fetch 绕过 typed SDK——一切基于 SDK 出口的闸门都可被绕开 #630
Description
来源:#619 的 R2 修复轮登记,owner 裁决(2026-07-26)另立票 —— 属全仓性问题,不在 #619 内堵。
问题
renderer 侧任何组件都可以绕开 typed SDK,直接 fetch() 打后端 HTTP 接口,
从而绕过一切建立在「SDK 出口」上的闸门。
这不是理论风险,有现成先例:
packages/ui-mac/src/renderer/sidebar/use-projects.ts:522
fetch(new URL("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/global/health", info.baseUrl), …)
照抄改成 POST 任意接口即可。
为什么现在提
#619 建立了「审批决定只能到达 Permission surface client」的闸门,
实现方式是把 SDK client factory 换成 recording proxy —— 属性访问链无拼写豁免,
连 client["v2"]["session"]["permission"]["reply"] 方括号取值都能抓。
但模块 alias 天然管不到裸 fetch。 实测确认:在 #619 的三条闸门下,
用裸 fetch 提交审批决定可以全绿逃逸。
同理 XMLHttpRequest / sendBeacon / WebSocket(renderer 内目前无先例,但同样无闸)。
这条对 #619 不是独有的 —— 它让任何基于 SDK 出口的不变量都可被绕过,
所以应当一次性在类层面处置,而不是逐个闸门打补丁
(见 memory「同一类第二次出现就从逐实例修切到枚举整类+单点修机制」)。
边界
packages/ui-mac/src/renderer/** 的网络出口。
先勘破:全仓有多少处直接 fetch/XHR/sendBeacon/WebSocket,各自是否正当。
Out-of-scope
- 不改 [REQ-125][CODE] 审批统一走独立 Permission surface——删除 dock 审批卡与 claim 抢占 #619 已交付的三条闸门(它们在各自射程内成立)
- 不改 main/preload 侧的网络行为
- 不为此重写 SDK 层
退出条件
- 枚举出 renderer 侧全部直接网络出口,逐个判定正当/应收编。
- 建立一个单点判据:renderer 生产代码不得绕过 typed SDK 直接发 HTTP
(正当例外进白名单并写明理由)。 - 反向闸门:新增一处裸
fetch到后端接口时有测试变红。 use-projects.ts:522这处既有先例得到处置(收编或列入白名单并说明)。
复杂度
M(全仓枚举 + 单点闸门;需先勘破正当例外的边界)
Activity
jinjunnn commentedon Sep 17, 2026
票面清理(2026-09-16):关闭 —— 过度工程,不适合当前项目。
这张票担心:桌面界面里的代码可以绕开正规调用通道、直接发网络请求,从而绕过建在正规通道上的开发期检查(例如「审批决定只能从审批面板发出」)。它要求全量枚举、单点检查和反向检查。实查今天的界面代码:直接发网络请求的只有一处,是侧栏的本机健康检查,只读、不带任何决定;界面的内容安全策略本来也只允许连本机服务。这些开发期检查防的是「我们自己写错代码」,不是安全边界——真有人能在界面里跑任意代码,正规通道他也一样能直接调。为一处只读健康检查造一道全局闸门,换不来可感知的改善,关闭。
证据(alpha-code origin/alpha):
packages/ui-mac/src/renderer下(排除测试)fetch(唯一命中sidebar/use-projects.ts:668(/global/health)XMLHttpRequest/sendBeacon/new WebSocket(零命中(同目录对WebSocket能命中注释与测试,检索有效)packages/ui-mac/src/main/renderer-security.ts的connect-src仅 self + 本机回环重开条件:界面代码里出现第二处直接请求后端的写操作,或发生一次绕过正规通道导致的真实错误。
如判断有误,直接重开即可;重开时请在评论里说明新出现的情况。