One carrier-level browser-trust boundary for all `/api` routes
所有 /api 路由共用一道载体级浏览器信任边界
The web GUI host serves `/api` over plain loopback HTTP (default `127.0.0.1:3080`; the CLI rejects `--host 0.0.0.0`), and the surface includes remote-code-execution-grade methods — `session.prompt` drives an agent that runs bash. A browser turns the operator into a confused deputy against such a local API in two classic ways: a malicious page fires a "simple" cross-site POST (`text/plain` — sent without a CORS prefli
English
Problem
The web GUI host serves /api over plain loopback HTTP (default 127.0.0.1:3080; the CLI rejects --host 0.0.0.0), and the surface includes remote-code-execution-grade methods — session.prompt drives an agent that runs bash. A browser turns the operator into a confused deputy against such a local API in two classic ways: a malicious page fires a "simple" cross-site POST (text/plain — sent without a CORS preflight) whose side effects execute even though the response stays unreadable, and a DNS-rebound origin talks to the socket as if same-origin, making CORS inapplicable entirely, with only the Host header betraying the attacker's domain. Before this decision the system's only browser-trust check (isTrustedNativeDialogRequest: loopback socket + same-origin + loopback Host) guarded exactly one cosmetic route — host.pickDirectory, whose native dialog pops on the host's screen — while every consequential method was unguarded. Guarding per-RPC also could not survive the in-app directory browser, whose whole point is serving legitimately remote clients that a loopback rule would refuse.
Decision
Enforce browser trust once, at the carrier, for the entire /api prefix — two halves:
- Media-type fence (dsh-client-connection): every
/apiPOST must declareapplication/json, else 415 before parsing. Cross-site "simple" requests thereby stop existing: any cross-site attempt is forced into a CORS preflight this server never answers. - Authority fence (dsh-client-connection,
src/api-request-trust.ts): every request must present aHostthat is loopback or matches atrustedHostsentry (exact onhost:port, any port on port-less entries, WHATWG-normalized; rebinding defense). Deliberately no shortcut for unmarked requests: over plain HTTP a browser attaches neitherOriginnor Fetch-Metadata to reads (EventSource, images, navigations — those headers go only to trustworthy destinations), so an unmarked request may be a rebound browser read whose response the page can read, and Host is the one header rebinding cannot forge; non-browser clients pass via loopback, a declared authority, or the listener's own bind literal that Bind one concrete Web address admits. An attachedOriginmust equal the Host authority;sec-fetch-site: cross-siteis refused outright. AtrustedHostsentry that is not a bare, canonical authority fails the plugin load — WHATWG parsing would otherwise quietly authorize the hostname inside a typo or broaden an exact-port grant.host.pickDirectoryloses its bespoke guard and rides the same fence.
Reachability is the webserver binding's policy (host; Bind one concrete Web address owns which literals it accepts), and this fence is a confused-deputy defense rather than identity. Connection applies the separate browser token authentication after the fence. The fence does not inspect peer socket addresses: binding expresses reachability, trustedHosts names accepted authorities, and the socket address adds nothing the Host/Origin checks need.
HostConnectionHandle.allowsRemoteAuthorities projects whether any validated trustedHosts entry names a non-loopback hostname: a loopback listener behind a proxy can still serve remote browsers, so the directory picker requires a policy without remote authorities before it picks the native chooser.
Alternatives considered
- Per-RPC guards (status quo extended). Rejected: the guard list trails the method list forever, the highest-value methods were already unguarded, and a loopback rule on browse RPCs would break the remote deployments they exist for.
- CORS headers + credential omission. Rejected: we never want cross-origin reads at all, so answering preflights only widens the surface; refusing them is strictly stronger and simpler.
- Authentication tokens. Rejected for this change: token minting, storage, and rotation are separate product decisions. The later browser token authentication owns them without changing this fence.
Consequences
- Any future
/apimethod is covered by construction; there is no per-route trust decision left to forget. - A non-loopback listener accepts its own bind IP directly (Bind one concrete Web address); other remote authorities require configured trust. Every accepted authority still requires browser authentication.
--trusted-hostextends only the Host/Origin fence and grants no identity. - Clients must label POST bodies
application/json(ours always did; raw-fetch tests gained the header). - Host and Origin remain request-routing evidence only. The process token and signed cookie establish the browser identity used by every Host method.
中文
问题
Web GUI 宿主以纯 loopback HTTP 提供 /api（默认 127.0.0.1:3080；CLI 拒绝 --host 0.0.0.0），而这个面上有远程代码执行级别的方法——session.prompt 驱动的 agent（智能体）可以运行 bash。浏览器会用两种经典方式把操作者变成攻击此类本地 API 的「混淆代理人」：恶意页面发出跨站「简单请求」 POST（text/plain——不经 CORS 预检即发出），其副作用照常执行、只是响应不可读；以及 DNS rebinding 后的源以「同源」身份直连 socket，CORS 整体失效，只有 Host 头会暴露攻击者的域名。在本决策之前，系统里唯一的浏览器信任检查（isTrustedNativeDialogRequest：回环 socket、同源、回环 Host）只守着一个装饰性的路由——host.pickDirectory，其原生对话框弹在宿主屏幕上——而所有真正具有严重后果的方法都没有防护。按 RPC 逐个设防也活不过应用内目录浏览器：它存在的意义就是服务合法的远程客户端，回环规则恰恰会拒绝它们。
决策
在载体层对整个 /api 前缀一次性执行浏览器信任检查——分为两部分：
- 媒体类型栅栏（dsh-client-connection）：每个
/apiPOST 必须声明application/json，否则在解析前以 415 拒绝。跨站「简单请求」由此不复存在：任何跨站尝试都被逼进一次本服务器从不应答的 CORS 预检。 - 权威栅栏（dsh-client-connection，
src/api-request-trust.ts）：每个请求的Host都必须是回环地址，或与某个trustedHosts条目匹配（带端口的host:port条目精确匹配，不带端口的条目匹配任意端口，均经 WHATWG 归一化；rebinding 防御）。刻意不为无标记请求开捷径：明文 HTTP 下浏览器的读取（EventSource、图片、导航——这些头只发给可信目标）既不带Origin也不带 Fetch-Metadata，因此无标记请求可能是被重绑页面发起且响应可被读走的读取，而 Host 是重绑唯一伪造不了的请求头；非浏览器客户端经由回环地址、已声明的权威，或绑定一个具体的 Web 地址所接纳的监听器自身绑定字面量通过。若带Origin则必须与 Host 权威完全一致；sec-fetch-site: cross-site一律拒绝。不是单纯规范化 authority 的trustedHosts条目会导致插件加载失败——否则 WHATWG 解析会悄悄授权笔误里的 hostname，或放大精确端口授权。host.pickDirectory失去专属守卫，与其他请求同栅而行。
可达性由 webserver 的绑定配置（host；绑定一个具体的 Web 地址拥有它接受哪些字面量）控制，这道栅栏是混淆代理人防御，而不是身份。Connection 在栅栏之后应用独立的浏览器令牌认证。栅栏不检查对端 socket 地址：绑定表达可达性，trustedHosts 点名接受的 authority，socket 地址提供不了 Host/Origin 校验需要的额外信息。
HostConnectionHandle.allowsRemoteAuthorities 表示是否有通过校验的 trustedHosts 条目命名非回环主机名：代理后的回环监听器也能服务远程浏览器，因此目录选择器要求策略不接纳远程 authority，才会选择原生交互。
曾考虑的替代方案
- 按 RPC 设防（延续现状）。 否决：守卫清单永远追着方法清单跑，价值最高的方法本来就没被守住，而 browse RPC 上的回环规则会破坏它们为之存在的远程部署。
- CORS 头与省略凭据。 否决：我们根本不想要任何跨源读取，应答预检只会扩大暴露面；拒绝预检严格更强也更简单。
- 认证令牌。 在本变更中否决：令牌签发、存储与轮换属于独立产品决策。后续浏览器令牌认证持有这些机制，不改变本栅栏。
后果
- 未来任何
/api方法天然在覆盖范围内；不存在会被遗忘的按路由信任决定。 - 非回环监听器直接接受自己的绑定 IP（绑定一个具体的 Web 地址）；其他远程 authority 需要配置的信任。每个被接受的 authority 仍须满足浏览器认证。
--trusted-host只扩展 Host/Origin 栅栏，绝不授予身份。 - 客户端必须给 POST 体标注
application/json（我们自己的客户端一向如此；裸 fetch 测试补上了该头）。 - Host 与 Origin 仍只是请求路由证据。进程令牌与签名 cookie 建立每个 Host 方法使用的浏览器身份。