多用户:聊天发送路径缺 thread 归属校验(潜在 IDOR,分享/导出会话前必修)

[mirror29]

背景

PR #129(多用户登录)修了 chat 会话读(listChatMessages)和改标题(setChatThreadTitle)两处越权,靠 apps/dashboard/src/lib/mastra.ts 的 ownsThread(取回 thread 校验 resourceId === 登录用户)。但聊天发送/续接主路径没有同源校验。

问题

• /api/copilotkit(apps/dashboard/src/app/api/copilotkit/route.ts)把 resourceId 强制设为 getSessionSubject()(可信),但 threadId 来自前端 <CopilotKit threadId>(客户端 crypto.randomUUID() 生成、存 localStorage,客户端可控)。
• mastra 侧 packages/orchestration/src/mastra/memory.ts 的 assertScopedRequest() 只校验 resourceId/threadId 非空,不比对已存在 thread 的 resourceId 是否等于调用方;且该函数目前只在 scheduler/runner.ts 调,聊天路径没调。
• identityMiddleware(mastra/index.ts)注释明确写它与 Memory 的 resourceId 机制"完全解耦",只管 AUTH_SUB_KEY 给 askCache 用,不 reconcile 请求体里的 resourceId/threadId。

影响(潜在,非当前可利用)

登录用户 B 若拿到用户 A 的 threadId,向 /api/copilotkit 发消息传 threadId=A的thread → mastra 侧无环节校验该 thread 归属 → B 的消息写进 A 的会话、B 本轮还可能读到 A 的历史上下文;A 下次打开该会话看到 B 注入的消息。

当前不可利用:threadId 是不可枚举的 UUIDv4,从不展示给其他用户、不进 URL、无"分享会话"功能 → 今天没有获取他人 threadId 的向量。属防御纵深缺口。

触发条件(务必在此之前修)

加任何会让 threadId 泄露的功能之前必须先修:分享会话 / 导出会话 / 把 threadId 放进 URL / 客服可见的会话链接 等。

建议修法

服务端(正确层次):在 mastra agent.stream/generate 前(或 identityMiddleware / 一个 input processor 里)对已存在的 threadId 加一次 resourceId 归属校验,复用 PR #129 ownsThread 思路——thread 存在且 resourceId !== 已认证 sub → 拒绝;不存在(新会话)或本人 → 放行。需先读 @mastra/memory 内部确认拦截点(PR #129 review 因沙箱无 node_modules 未能二次交叉确认,置信度高但非 100%)。

备选:dashboard BFF 在 /api/copilotkit 解析 threadId 做同样 3 态校验(新建/本人/他人),但要解析并重建 CopilotKit 请求体流,较 fragile。

来源

PR #129 第 5 轮 auto-review。同根问题的兄弟修复已在该 PR 落地(读/改标题两处)。

[mirror29]

结论:框架层已拦住,非可利用 IDOR;补了回归守卫

深挖 mastra 内核(PR #129 时沙箱缺 node_modules 未能确认的部分)后确认:

1. 发送路径恒用可信 resourceId:@ag-ui/mastra 的 MastraAgent 调 agent.stream 时传 memory: { resource: this.resourceId ?? threadId },而 this.resourceId = getRemoteAgents({ resourceId }) 注入的值,dashboard 侧固定为 getSessionSubject()(登录用户,不可被客户端篡改)。客户端只能控制 threadId。
2. thread 按 resourceId 过滤:生产所用 LibSQLStore.getThreadById({threadId, resourceId}) 在传入 resourceId 时把它并入 WHERE(id=? AND resourceId=?),他人 thread 直接查不到(返 null);mastra 的 working-memory 工具在 thread.resourceId !== resourceId 时抛错。
3. 直证:新增回归测试 packages/orchestration/tests/memory.test.ts —— memory.getThreadById(threadId=A, resourceId=B) 返 null、resourceId=A 正常。即登录用户 B 即便拿到 A 的 threadId,mastra 加载 B 的上下文时也拿不到 A 的 thread/历史,B 的消息写在 B 自己的 resource 下;workingMemory 是 scope:"resource" 按可信 resourceId 键,也不泄露。

所以第 5/6 轮 auto-review 担心的"聊天发送路径消息泄露/注入"在当前栈(LibSQLStore + mastra 内核)已被框架拦住,不是可利用漏洞。auto-review 当时是基于应用层证据 + 显式 <100% 置信度提出的。

回归守卫已合入 PR #129(commit 4e176e2):若未来升级 mastra 悄悄去掉 resourceId 过滤,该测试会红。

残留(低,单独视需要):thread 元数据行层面若走 create-on-missing 分支可能被 saveThread 覆写("过继" thread 归属,但不泄露 A 的消息)——需 B 知道 A 的 threadId(无泄露向量)且影响仅为 A 丢失该会话标题。暂不处理。

据此关闭。