DSH Desktop：认证 Cookie 无界累积导致启动失败（HTTP 431 / Web authentication failed）

[sunqqq001]

DSH Desktop：认证 Cookie 无界累积导致启动失败（HTTP 431）

缺陷报告 / Bug Report — 2026-10-29
仓库：deepseek-ai/deepseek-harness
性质：本地可用性缺陷（无界资源累积），非远程可利用漏洞

---

0. 摘要

DSH Desktop 每次启动都以随机端口拉起本地 Host（--port 0），而浏览器认证 Cookie 的名称由
authority（含端口）的 SHA-256 派生。端口每次变化 ⇒ Cookie 名每次变化 ⇒ Chromium 视为
不同 Cookie 新增而非覆盖。该 Cookie 有效期默认 30 天，且代码中没有任何清理逻辑。

累积约 70 条后，Cookie 请求头达到 Node http 的默认 maxHeaderSize（16384 字节），
本地 Host 在解析请求头阶段直接返回 431 Request Header Fields Too Large，启动流程随即抛出
desktop welcome: Web authentication failed，应用无法进入。

实测：一台日常使用的机器在 9 天内累积 62 条（13.79 KB，已达阈值 86%），再启动约 7 次即触发。

English TL;DR — DSH Desktop launches its local Host on a random port each start
(--port 0), while the auth cookie name is derived from sha256(authority), which includes
that port. Every launch therefore creates a new cookie instead of overwriting the old one.
Cookies live 30 days by default and are never pruned. After ~70 launches the Cookie request
header exceeds Node's default 16 KB maxHeaderSize, the Host replies 431, and startup throws
desktop welcome: Web authentication failed. Measured: 62 cookies / 13.79 KB after 9 days on a
single machine — roughly 7 launches from failure.

---

1. 环境

项目	值
产品	DeepSeek Harness Desktop (@deepseek-ai/dsh-desktop)
Desktop 版本	0.2.1-rc.3
dsh runtime 版本	0.2.1-rc.3
构建提交	be72761ee1a6736ebcdf4f3739363b083ae53c98（dshBuildDirty: false）
Electron	43.3.0
Node	22.23.4（随包 runtime）
操作系统	Windows（路径以 %APPDATA% 表示）
更新通道	nightly

相关文件（安装目录）：resources/app/lib/main.js、
resources/app/dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js、
resources/app/dsh/node_modules/@deepseek-ai/dsh-client-connection/lib/index.js。

---

2. 影响

• 可用性：累积到阈值后 DSH 完全无法启动；重启无效，因为重启既不清 Cookie 也不报错
  （机制见 §4.5 / §4.6）。
• 性能：阈值以下时，每个发往本地 Host 的请求（含全部 /api/* 调用）都要额外携带
  数十 KB 的 Cookie 头。62 条时单请求约 14.4 KB（Cookie 头 14,116 B + 其余头约 600 B），
  属纯上行浪费。
• 可自愈性：需等待最早一批 Cookie 过期（30 天），或手工删除 Cookie 数据库。
• 影响面：所有使用 Desktop 版、且频繁启停的用户；与配置无关，属默认行为。
• 豁免条件：若以固定端口运行 Host（如 dsh web --port <固定值>，使 authority 稳定），
  则 Cookie 同名覆盖、不会累积。Desktop 的启动路径正是每次都传 --port 0，故必然命中。

---

3. 复现步骤

1. 正常安装并启动 DSH Desktop，登录/使用，然后完全退出（含系统托盘）。

2. 重复启动—退出 N 次（每次间隔不限）。

3. 每次启动后检查 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies（SQLite），可见：

   SELECT COUNT(*) FROM cookies;                     -- 随启动次数线性增长
   SELECT name, value FROM cookies WHERE name LIKE 'dsh-auth-%';

   每条 name 为 dsh-auth-<base64url(sha256("127.0.0.1:<port>"))>，<port> 各不相同。

4. 当 SUM(length(name) + length(value) + 3) 接近 16384 时，启动开始失败。

无副作用验证 431 阈值（对正在运行的实例发不同大小的 Cookie 头，见附录 B）：

cookie≈16000B -> HTTP 401 Unauthorized
cookie≈16300B -> HTTP 401 Unauthorized
cookie≈16400B -> HTTP 431 Request Header Fields Too Large

阈值落在 16300–16400 之间，与 Node http 默认 maxHeaderSize = 16384 完全一致。

---

4. 根因分析

4.1 每次启动使用随机端口

dsh-desktop-host/lib/index.js:234-240：

args: [
  "--no-open",
  "--host",
  "127.0.0.1",
  "--port",
  "0"          // ← 0 = 由操作系统分配随机端口
],

实测该机器的 62 条认证 Cookie 对应 62 个互不相同的端口
（19387、6746、7028、7859、9114、48533、40324…），无一条重复。

4.2 Cookie 名绑定 authority（含端口）

dsh-client-connection/lib/index.js:335-336：

function cookieName(authority) {
  return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest());
}

其中 COOKIE_PREFIX = "dsh-auth-"（:277），authority 由 requestAudience() 生成，
在明文 HTTP 下等于 Host 头，即 127.0.0.1:<port>（:307-316）。

⇒ 端口变，名称变，旧的不会被覆盖。

4.3 Cookie 有 30 天有效期

dsh-client-connection/lib/index.js:1017：

cookieMaxAgeDays: z.natural().min(1).default(30),

签发时写入 Max-Age 与 Expires（:347-349）。实测 expires = created + 30d，与代码一致。

4.4 没有任何清理逻辑

• dsh-client-connection 中对该 Cookie 只有 set（:473-478、:532-537），
  无任何 remove / 删除路径。
• main.js 中仅有的 clearStorageData 调用位于安装器接管（:6961）与策略登录窗口销毁
  （:10261），均不涉及主 defaultSession。

4.5 失败点与报错措辞

启动链路（main.js:12208-12214）：

const ready = await host.start();
hostCookie = await authenticateWebHost(ready.url);   // ① Node fetch，不读 Cookie jar
...
welcomeBackend = await connectDesktopWelcome(ready.url,
  (input, init) => net.fetch(input, init), ...);      // ② Electron net.fetch，读 jar

• ① authenticateWebHost（main.js:8248-8255）使用 Node 全局 fetch，不携带 Chromium
  Cookie jar，因此总能成功拿到 303 + Set-Cookie，不会先报 Desktop Host authentication failed（:8252）。
• ② connectDesktopWelcome（main.js:8901-8905）使用 Electron net.fetch 且
  credentials: "include"，会把 jar 中全部 62 条 Cookie 一并发出 ⇒ 命中 431 ⇒
  authenticated.ok === false ⇒ 抛出 desktop welcome: Web authentication failed。

这解释了为什么用户看到的正是 Web authentication failed，而非更早的认证错误。

4.6 为什么"重启没救"

431 发生在 Node 解析 HTTP 请求头阶段，请求尚未进入应用逻辑，authorizeIndex() 不会被调用，
因此不会签发新 Cookie（条数冻结，不继续恶化）；但同样不会删除旧 Cookie。
用户重启只会重复失败，直到最早一批 Cookie 越过 30 天有效期
（Chromium 的持久化 Cookie 存储会在初始化时清理过期项——按实现推断，未在此次实测中观测到，
因现存数据均未过期）。

---

5. 实测证据

来源：单台日常使用机器，2026-10-20 → 2026-10-29（9 天）。

指标	数值
cookies 表总条数	62
host_key	全部 127.0.0.1（无其它域）
不同端口数	62（一一对应，无重复）
dsh-auth-* 条数	62
name 总长	3,224 B（平均 52 = dsh-auth- 9 + base64url(sha256) 43）
value 总长	10,706 B（平均 173；v2.<base64(JSON)>.<hmac>）
拼成单个 Cookie 头	14,116 B = 13.79 KB
Node maxHeaderSize	16,384 B
占用率	86%
距 431 剩余	约 7 次启动
每条 Cookie 尺寸	52 + 1 + 173 + 2 ≈ 227 B
理论临界条数	16384 / 227 ≈ 72

注：72 恰为传言中流出的数字，与阈值换算吻合。

Cookie 结构样例（值已脱敏，仅展示形状）：

name : dsh-auth-<base64url(sha256("127.0.0.1:19387"))>   // 共 52 字符
value: v2.<base64url(JSON: {"version":2,"authority":"127.0.0.1:19387",
         "issuedAt":<ms>,"expiresAt":<ms>})>.<base64url(HMAC-SHA256)>
attrs: Max-Age=2592000; Path=/; Expires=<issuedAt+30d>; HttpOnly; SameSite=Strict

所有条目 is_persistent = 1、is_httponly = 1。

---

6. 修复建议

方案 A（最小改动，推荐落地）：启动时清理陈旧 Cookie

在 main.js 的 host 启动完成后、connectDesktopWelcome 之前，清掉全部历史 dsh-auth-*：

const jar = await session.defaultSession.cookies.get({});
for (const c of jar) {
  if (c.name.startsWith("dsh-auth-")) {
    await session.defaultSession.cookies.remove("http://127.0.0.1", c.name);
  }
}

注意需在 authenticateWebHost() 之后执行，以免误删本次刚签发的条目；或按
expiresDate 保留最新一条。此方案不改变现有安全模型。

方案 B（更优雅，根治）：名称按 hostname 派生，authority 仍由 payload 校验

cookieName() 的输入改为 hostname（不含端口），但保留 authenticate() 中
payload.authority !== authority 的校验（:566）：

• 不同端口共用同一 Cookie 名 ⇒ 后者覆盖前者，永不累积；
• 旧端口的 Cookie 因 payload.authority 不匹配而拒绝，安全性不变；
• 每次启动仍会重新走 launch-token 换取 Cookie，行为一致。

代价：多实例（不同端口）并行时，后启动者会使前者失效——但 Desktop 有单实例锁，实际影响可忽略。

方案 C：固定端口

让 Desktop 使用固定或稳定端口（如优先 26411，占用时递增并持久化）。
可从根上消除 authority 漂移，但依赖端口分配的稳定性，不如 A/B 彻底。

附带建议

• 为 WebServer 显式设置 maxHeaderSize，或至少在超限时返回可诊断的错误页，
  而非仅有空响应体的 431。
• 将 431 映射为用户可理解的提示（当前用户只能看到认证失败，无法联想到 Cookie 累积）。
• 增加一个启动自检：若 dsh-auth-* 条数 > N 或请求头 > 阈值，先清理再启动并记录日志。

---

7. 用户侧临时缓解

1. 完全退出 DSH（含托盘；SQLite 独占锁住该文件，不退出无法删除）。
2. 删除 %APPDATA%\@deepseek-ai\dsh-desktop\Network\Cookies 与 Cookies-journal。
3. 重新打开 DSH。

不会丢数据：会话与配置位于 %USERPROFILE%\.dsh（sessions/ 等），不在该目录；
且该 Cookie 库内全部条目均为 127.0.0.1，删除仅丢失本地登录态，重开时自动重新签发一条。

配套脚本见附录 A（先检查进程、备份、再删，支持只读报告模式）。

---

8. 补充

• 不含远程利用路径，也未对任何第三方系统造成影响；全部测试在本人自有机器上完成，
  只读探测未修改目标状态。
• 本报告未包含任何 Cookie 值（仅长度与结构），请勿在讨论中要求粘贴。
• 可提供复现脚本（PowerShell / Node，见附录），并可配合验证修复。
• 如项目设有 credits / 赏金机制，欢迎记录本次披露；若无，也希望能看到修复确认。

---

附录 A：诊断与清理脚本

结构已在 Windows PowerShell 5.1 + Node 22.23.4 上验证；提交前请先只读运行确认。

# 1) 彻底退出 DSH（含托盘）后运行
$cookiePath = Join-Path $env:APPDATA '@deepseek-ai\dsh-desktop\Network\Cookies'
if (Get-Process -Name 'DeepSeek Harness' -ErrorAction SilentlyContinue) {
  throw 'DSH 仍在运行：SQLite 独占锁，必须先退出'
}

# 2) 备份
Copy-Item -LiteralPath $cookiePath `
  -Destination "$cookiePath.bak-$(Get-Date -Format yyyyMMdd-HHmmss)" -Force

# 3) 统计（先复制副本，避免占用锁）
$tmp   = Join-Path $env:TEMP 'dsh-ck-copy.db'
$probe = Join-Path $env:TEMP 'dsh-ck-probe.mjs'
Copy-Item -LiteralPath $cookiePath -Destination $tmp -Force
@'
import { DatabaseSync } from 'node:sqlite';
const db = new DatabaseSync(process.argv[2], { readOnly: true });
const rows = db.prepare('SELECT name, value FROM cookies').all();
const auth = rows.filter((r) => r.name.startsWith('dsh-auth-'));
let bytes = 0;
for (const r of auth) bytes += r.name.length + 1 + r.value.length + 2;
db.close();
console.log(JSON.stringify({ total: rows.length, auth: auth.length, bytes }, null, 2));
'@ | Set-Content -LiteralPath $probe -Encoding utf8
node --no-warnings $probe $tmp
Remove-Item $probe, $tmp -Force

# 4) 确认统计后再执行清理（取消下面两行注释）
# Remove-Item -LiteralPath $cookiePath -Force
# Remove-Item -LiteralPath "$cookiePath-journal" -Force -ErrorAction SilentlyContinue

附录 B：431 阈值探测

保存为 probe-431.mjs（需要 .mjs，因为使用顶层 await）。

import http from 'node:http';
const PORT = 26411;                       // 换成当前实例端口
for (const n of [14000, 16000, 16300, 16400, 17000]) {
  const cookie = 'dsh-auth-probe=' + 'x'.repeat(n);
  await new Promise((ok) => {
    http.request({ host: '127.0.0.1', port: PORT, path: '/', method: 'GET',
      headers: { host: `127.0.0.1:${PORT}`, cookie } }, (res) => {
        console.log(`${n}B -> ${res.statusCode}`); res.resume(); res.on('end', ok);
      }).on('error', () => ok()).end();
  });
}

实测输出：

14000B -> 401
16000B -> 401
16300B -> 401
16400B -> 431
17000B -> 431

---

报告基于安装包内代码静态阅读 + 运行实例只读探测，未修改目标状态；Cookie 值未在本文中披露。