fix(security): 中危批次——本地代理 SSRF、terminal attach 限速、SVG XSS、frame 防护、分享脱敏、git 门控大小写、history 事件健壮性

[zayokami]

背景

安全审计中危项(confirmed×2 为主)的 7 项修复(issue #515),每项带复现/回归测试(先在未修复代码上证明问题存在,修复后转绿)。

Closes #515

Screenshots / preview

本次改动为协议/运行时逻辑(SSRF 过滤、限速、响应头、脱敏、门控),无 UI 视觉变化;以下是各修复的复现测试证据(before/after):

修复内容

1. 桌面本地 /image-proxy SSRF(confirmed×2)

• 漏洞:validate_image_proxy_url 只校验 scheme/host/凭据,127.0.0.1、内网、169.254.169.254 云元数据全部可访问;端点无 token、CORS *
• 修复:URL 增加与网关 Go 侧对齐的字面 IP 黑名单(回环/私网/link-local/元数据/多播/保留/广播,含 localhost 主机名);并增加 Origin 来源校验(仅放行 Tauri WebView 来源,恶意网页 fetch 被拒)。<img> 路径不带 Origin,由 IP 黑名单兜底
• 测试:SSRF 目标拒绝用例 + origin 白名单用例

2. /ws/v2/terminal 浏览器链路无界 attach(confirmed×2)

• 漏洞:读循环无限速、attach 帧把任意长度/数量的 session_id 存进无界 map,单连接 OOM;对照主链路有 100fps 限速
• 修复:入站限速与主链路同款(100fps/突发 200/3 次违规断连);attach 跟踪表容量(512)与 id 长度(512)上限
• 测试:容量封顶 + 超长 id 拒绝用例

3. SVG XSS on gateway origin(confirmed×2)

• 漏洞:未认证 /image-proxy 把攻击者 SVG 以 image/svg+xml 直出,无 CSP/Content-Disposition,顶层导航即在网关 origin 执行脚本窃取 localStorage 里的管理员 token
• 修复:SVG 响应加 Content-Security-Policy: sandbox + Content-Disposition: inline,降级为纯图片源
• 测试:SVG 响应头断言 + 非 SVG 不受影响

4. WebUI 点击劫持(finder)

• 漏洞:无 X-Frame-Options/frame-ancestors,token 自动登录可被第三方 iframe 嵌入诱导点击
• 修复:serveIndex 加 X-Frame-Options: DENY + frame-ancestors 'none'
• 测试:index 响应头断言

5. Public-share 脱敏绕过(confirmed×2)

• 漏洞:redact_tool_content 只处理 assistant/toolResult,role=summary 的归档段摘要(含工具输出浓缩)原样流出公开分享页
• 修复:redactor 新增 summary 分支,redact 语义下整体替换为占位(摘要无法可靠剥离工具内容)
• 测试:summary 泄漏用例(密钥/路径不得出现在输出)

6. enable_web_git 大小写绕过(1 plausible/1 refuted 的窄通道)

• 漏洞:网关侧 gitActionIsWrite 精确匹配,桌面侧 to_ascii_lowercase,CLONE_START/Push 等变体过门控却在桌面执行写操作
• 修复:网关侧 action 先 ToLower 再判写
• 测试:TestV2GitRejectsCaseMutatedWriteActionsWhenDisabled(修复前:变体被放行=复现)

7. history.event 缺 conversation 字段崩溃(plausible×2)

• 漏洞:网关可发不带 conversation 的 upsert,normalizeGatewayConversationSummary(undefined) 抛 TypeError 中断后续监听者投递
• 修复:跳过无 conversation 的 upsert 帧;reconciliation 对 message_count 加 optional chain
• 测试:web-sidebar-backend 用例(修复前:抛异常=复现)

回归

域	结果
Go(网关)	✅ 全过(仅基线 Windows 权限测试,与本次无关)
Rust(桌面)	✅ 改动域 129 个测试全过
WebUI	✅ 579 个测试全过
lint / diff --check	✅ 干净(仅仓库既有 CRLF)

行为变更说明

• 桌面本地代理不再代理内网/回环图片 URL(模型输出的公网图片不受影响)
• 分享开启"脱敏工具内容"时,历史段摘要将被整体脱敏替换
• WebUI 页面禁止被 iframe 嵌入

🤖 Generated with Claude Code

[github-actions]

PR governance checks passed. Awaiting human review.

[su-fen]

审查结论：暂不建议直接合入，当前有两个安全阻塞问题。

1. 桌面 /image-proxy 的 SSRF 修复仍可绕过

crates/agent-gui/src-tauri/src/services/proxy.rs 的 validate_image_proxy_url 只拦截字面 IPv4 黑名单和 IPv6 回环 ::1，请求随后交给默认会跟随重定向的共享 reqwest client。因此以下路径仍可访问本机或内网：

• 攻击者域名解析到 127.0.0.1、169.254.169.254 或 RFC1918 地址；
• 公网 URL 通过 30x 跳转到内网地址；
• fc00::/7、fe80::/10 等内网/link-local IPv6；
• IPv4-mapped IPv6，例如 http://[::ffff:127.0.0.1]/。

这意味着原 SSRF 边界没有完整封住。建议在实际连接阶段检查 DNS 解析出的全部地址，并在每次重定向时重新校验；同时覆盖完整 IPv6 禁止段并先 unmap IPv4-mapped IPv6。需要增加 DNS、重定向和 IPv6 绕过回归测试。

2. terminal ID 长度限制仍可造成单连接高内存占用

crates/agent-gateway/internal/protocol/pbws/terminal_conn.go 的 remember 先执行 strings.TrimSpace，再检查 512 字节长度并把结果放入 map。Go 的字符串切片会继续持有原字符串的整块底层内存，因此攻击者可以发送“接近 1 MiB 的空白前缀 + 短且唯一的 ID”；trim 后长度合法，但每个 map key 仍可能保留接近 1 MiB。填满 512 个 key 后，单连接仍可长期保留数百 MiB，原 OOM/内存 DoS 风险并未真正消除。

建议在 trim 前限制原始字段长度，对规范化后的 key 使用有界复制，并在超长或容量已满时明确拒绝该 attach、不要继续转发给 Agent。现有测试只覆盖无空白的超长字符串，未覆盖这一保留内存路径。

其他合入检查

• 与最新 main 的临时合并无冲突；
• WebUI 构建成功，测试 580/580 通过；
• Rust 相关定向测试 21/21 通过，但没有覆盖上述绕过；
• cargo fmt --all --check 在本 PR 新增 Rust 代码上有 3 处格式差异；
• 本机没有 Go 工具链，因此未独立复跑 Go 测试。

建议修复以上两个安全问题、补齐绕过测试并执行格式化后再合入。

[zayokami]

已按审核意见修订两个安全阻塞问题,新 SHA 已推送(f1d7510)。

1. /image-proxy SSRF 完整封堵

• IPv4-mapped IPv6:is_blocked_image_proxy_ip 统一入口先 to_ipv4_mapped() 还原再走 IPv4 黑名单(对齐网关 outbound_http.go 的 Unmap() 先例);http://[::ffff:127.0.0.1]/、[::ffff:169.254.169.254]/ 均被拒绝,测试覆盖。
• 完整 IPv6 禁止段:与 Go 侧 blocked prefixes 逐项对齐——::/::1、64:ff9b::/96(NAT64)、64:ff9b:1::/48、100::/64、2001::/23、2001::/32(Teredo)、2001:2::/48、2001:10::/28、2001:20::/28、2001:db8::/32、2002::/16(6to4)、3fff::/20、5f00::/16、fc00::/7(ULA)、fe80::/10、ff00::/8。
• DNS rebinding:连接前对主机名做 tokio::net::lookup_host 全地址解析,任一命中黑名单即拒绝,fail-closed(解析失败也拒绝);测试覆盖 localhost.(尾点,不命中字面拦截、解析命中回环)与无效域名。
• 重定向:reqwest 0.13 的重定向策略是 client 级配置,image-proxy 改走 system_proxy::async_client_builder(同代理语义)并设置 custom redirect policy——每次 30x 跳转重新校验目标(字面 IP/localhost/凭据/scheme/主机名解析)。测试覆盖每跳校验的各拒绝路径与公网放行。

2. terminal attach ID 内存保留

• remember 先按原始字段长度(4 KiB)拒绝再 trim——"接近 1 MiB 空白前缀 + 短 ID"在 trim 前即被拒,不再进入 map;规范化后 ≤512 并做有界拷贝(string([]byte(...)))切断与整帧缓冲区的引用。
• 超长/空 id/容量已满均返回明确错误,handleFrame 回错误帧且不再转发给 Agent(此前超长被静默丢弃、超限仍转发)。
• 测试:空白前缀绕过用例(旧实现会接受)、handleFrame 拒绝路径验证(队列只有拒绝帧而非转发路径的 offline 帧)、容量满拒绝、合法 attach 不受影响。

格式化:cargo fmt --check 现为 0 差异(修复了原 3 处)。

回归:Rust 受影响域 46/46(含 proxy 22 个测试);Go internal/... + test/websocket 全过,全量仅既有 Windows 权限位基线失败;WebUI 未触及。

[su-fen]

复审结论：暂不建议直接合入。当前 PR 可合并且 CI 已全绿，但仍有两个安全阻塞问题。

1. 桌面 /image-proxy 的 DNS 校验没有绑定到实际连接，SSRF 仍可被 DNS rebinding 绕过

crates/agent-gui/src-tauri/src/services/proxy.rs 中，初始请求先通过 image_proxy_host_resolves_to_blocked 独立解析并检查地址，之后由新建的 reqwest client 执行 .send()；client 没有配置使用前面得到的已校验地址，因此实际连接会再次解析域名。攻击域名可以在预检查时返回公网 IP、在实际连接时返回 127.0.0.1、RFC1918 或云元数据地址。

重定向路径也有同样问题：redirect policy 内的 to_socket_addrs() 只是一轮预检查，follow 后实际连接仍会再次解析。启用应用代理时，目标域名还可能由 HTTP/SOCKS 代理端解析，客户端预检查与实际目标进一步脱钩。

建议把 IP 黑名单放进实际连接使用的 DNS resolver/connector，并让 connector 只使用本轮已审核的地址；重定向每一跳都必须走同一安全 resolver。若需要继续支持应用代理，还需要明确代理模式下如何保证目标解析和连接同样受限。回归测试应使用可控 resolver 验证“第一次公网、第二次内网”的切换，而不只是单测预检查函数。

2. terminal 入站限速可被文本帧绕过，且发生在反序列化之后

crates/agent-gateway/internal/protocol/pbws/terminal_conn.go 的 readTerminalFrame 会对所有非二进制 WebSocket 消息直接 continue，而 rateLimiter.Allow() 只在该函数返回一个已完成 protobuf 反序列化的二进制帧后执行。因此：

• 握手前可无限发送文本帧，占用 terminal connection slot，完全不经过限速；
• 认证后文本帧仍不计入限速；
• 大型二进制帧先完成读取和 protobuf 反序列化，之后才被限速丢弃，无法真正限制解析 CPU。

建议在每次 ReadMessage() 成功后立即计数，非二进制帧直接拒绝或同样计入限速；握手阶段也应有超时/帧率边界。请补充文本帧绕过以及“限速发生在反序列化前”的回归测试。

验证情况

• GitHub 8 项状态检查全部通过，merge state 为 CLEAN；
• 本地 Rust 相关测试 23/23 通过，cargo fmt --all --check 与 git diff --check 通过；
• WebUI 新增回归用例 8/8 通过，生产构建通过；
• 本机无 Go 工具链，Gateway Go 测试以 CI 全绿为准。

请修复以上两个安全边界问题后再合入。

[zayokami]

两个安全阻塞问题已修复（52f818f5），CI 待跑。

1. image-proxy DNS rebinding

已将 IP 黑名单装进 reqwest 实际拨号使用的 DNS resolver（ImageProxyResolver，proxy.rs）：

• 绑定原理：hyper 对主机名目标每次新建连接都调用该 resolver，且只拨号本轮回填的地址——审核结果与连接目标一一对应，不存在第二次独立解析。重定向跨 origin 的每一跳必然新建连接，自动重走同一安全 resolver 再审；同 origin 跳转复用的是当初已过审的连接本身，无重新解析窗口。
• fail-closed：任一地址命中黑名单即整体拒绝（不允许从混合答案中挑出内网地址），空答案/解析失败同样拒绝。字面 IP 不经 resolver（hyper 短路），仍由 validate_image_proxy_url 与重定向策略的字面量检查拦截。
• 代理模式：socks5h 已翻转为 socks5（system_proxy::async_client_builder_local_dns）——目标经安全 resolver 本地解析后把 IP 交给代理，解析与连接保持绑定；图片代理本就本地预解析目标，无新增 DNS 暴露。HTTP 代理（CONNECT/absolute-URI）协议只携带主机名，目标解析确在代理端完成、客户端无法绑定，残余窗口由前置预检 + 每跳重定向预检收缩，触达面限于代理所在网络位置；已在 ImageProxyResolver 注释中明确说明。已启用代理的主机名（用户设置，非攻击者输入）在 resolver 中豁免，避免回环/内网代理端点被误杀导致图片代理整体不可用。
• 回归测试：脚本化可控 resolver 验证"第一次公网、第二次内网"翻转在拨号前被拒；混合/空/失败答案 fail-closed；代理主机豁免不扩散。集成测试以本地回环 HTTP 服务器证明被否决的解析不产生任何实际连接（对照组放行谓词下同一地址可达）。

2. terminal 入站限速

• 计数点移到每次 ReadMessage() 成功后、proto 反序列化前（readTerminalFrame 内）：文本帧同罪计入；超限帧在解析前即丢弃（denied 三态返回，浏览器角色回 "too many requests"）；连续违规超阈值判死。
• 握手阶段：限速器自第一帧起生效，浏览器角色握手后沿用同一预算（攻击者不能借完成握手重置额度）；新增 10s 握手绝对读超时（terminalHandshakeTimeout），空连接/慢速流同样被边界。
• 主链路 browser_conn.readFrame 存在完全相同的形态（文本帧 continue 不计数、Allow 在 Unmarshal 之后），已同款修复——否则两条链路语义不一致。
• Agent 数据面（已认证桌面端）未加帧率限制：输出帧没有可容忍的丢帧语义（静默丢弃会让终端显示残缺），其入站由 read limit + 会话通道背压兜底，注释中已说明。如需对 Agent 角色也设上限，建议后续单独设计（如输出合并），不在本轮扩大改动面。
• 回归测试：文本帧耗尽突发额度后合法帧被拒且三次违规判死；非法 protobuf 帧在反序列化前被丢弃（连接存活、回填后后续帧正常解析——旧顺序下连接已关闭）；pre-hello 300 帧文本洪泛被判死；沉默连接被握手超时关闭；合法浏览器 hello 正路放行；主链路读路径同款两个测试。

验证

• Rust proxy/system_proxy 相关 41/41 通过，cargo fmt --all --check 干净；
• Gateway：go build/go vet 干净，pbws 包全部测试通过，golangci-lint run ./... 0 issues（本机已有 Go 工具链，补齐了上一轮的本地验证缺口）；
• git diff --check 干净。
• 本机 Windows 上 agenttoken 文件权限测试与 12 项 git worktree/hook Rust 测试在干净树上同样失败，为既有环境限制，与本次改动无关。