WeKan 9.23 BFLABleed 漏洞修复与回归测试解析：未 await 的异步访问检查（2026-05-19 测试记录）-平芜编程栈

后端
前端
协同办公

【免费下载链接】wekan

The Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan . No telemetry.

项目地址：https://gitcode.com/GitHub_Trending/we/wekan

点击查看免费下载

导读

本文基于 docs/Tests/03_2026-05-19.md 这份测试记录展开，围绕 WeKan 9.23 版本修复的BFLABleed安全漏洞（由 Fredrik Dietrichson 报告、xet7 修复）及其配套回归测试展开。读完本文，你将理解"异步访问检查未被await会导致越权"这一漏洞形态的完整成因，掌握 WeKan 源码中Authentication系列检查函数的真实调用链，并了解tests/unawaitedAccessCheck.test.cjs这类"从源码定义反推扫描点"的回归测试是如何做到全树覆盖的。

测试记录的背景：WeKan 9.23 安全修复

docs/Tests/03_2026-05-19.md全文虽短，却记录了一个关键的安全里程碑：WeKan 9.23 修复了 BFLABleed，并随后修复了相关测试。对应版本发布说明可在 old-CHANGELOG/2026/05.md 中找到：

v9.23 2026-05-21 修复了以下 CRITICAL SECURITY ISSUES：BFLABleed（commit8baa9124a607e0620ab72d6d16871ed1c08e721a），感谢 Fredrik Dietrichson 与 xet7。同时"Fix tests. Added Filter test at part 4"，测试修复对应 commit1b1b04d083efd44163549f7dc1f33aba6ae08c86与24577ad2a9647a3dc5143606d8ff9c23f6c49bd0。

这份测试记录与发布说明相互印证：漏洞修复（8baa9124）在先，测试修复（1b1b04d0）随后落地，二者共同构成了 9.23 版本的安全闭环。

BFLABleed 的漏洞本质：Promise 是 truthy

BFLABleed 并非传统意义上的注入或缓冲区问题，而是一个典型的异步访问检查使用错误（un-awaited async access check）。要理解它，必须先看 WeKan 的认证基础设施。

异步访问检查的源码定义

WeKan 将所有 REST API 的访问控制集中在 server/authentication.js 的Authentication对象中，其中五个关键检查函数全部声明为async：

checkUserId(userId)（server/authentication.js#L28-L41）：站点管理员检查，非管理员抛出 403；
checkLoggedIn(userId)（server/authentication.js#L45-L51）：登录状态检查，未登录抛出 401（注意它是同步函数）；
checkAdminOrCondition(userId, otherReq)（server/authentication.js#L55-L63）：满足条件或为管理员则通过；
checkBoardAccess(userId, boardId)（server/authentication.js#L66-L80）：检查调用者是否为该板的活跃普通成员/管理员；
checkBoardWriteAccess(userId, boardId)（server/authentication.js#L84-L100）：检查调用者是否具备板的写入能力（复用与 DDP 权限一致的allowIsBoardMemberWithWriteAccess能力表）；
checkBoardAdmin(userId, boardId)（server/authentication.js#L103-L120）：检查调用者是否为板管理员。

这些函数抛出的都是带statusCode的Meteor.Error（401/403/404），最终由 REST 路由转换为对应的 HTTP 状态码。

漏洞机理：不 await，检查形同虚设

问题恰恰出在这些检查函数的async声明上。测试文件 tests/unawaitedAccessCheck.test.cjs#L3-L11 对漏洞机理给出了精确描述：

一个async访问检查返回的是一个 Promise，而 Promise 是 truthy，并且在调用点永远不会抛出：Authentication.checkBoardAccess(userId, boardId);—— 缺少await会让处理器对任何人继续执行，其 rejection 无处可去。BFLABleed 就是 48 个以这种方式编写的 REST 端点，它们让已登录的非成员可以读写任意看板。

也就是说，如果路由处理器写了：

Authentication.checkBoardAccess(req.userId, boardId); // 忘了 await

那么这行代码只是创建了一个被"发射后不管"（fire-and-forget）的 Promise。即使该用户根本没有该板的访问权限，拒绝也会发生在 Promise 内部，而路由处理器已经继续往下执行，进入对任意板的读/写逻辑。JavaScript 中"Promise 永远为真、错误不会同步抛出"的语义，使这种检查变成一纸空文——这正是 BFLABleed 被归类为authz（broken access control）的原因。

同类漏洞：ExcelBleed

同一错误形态还出现在 Excel 导出路由上，被命名为 ExcelBleed。在 models/exportExcel.js#L68-L149 的GET /api/boards/:boardId/exportExcel路由中，修复后的代码明确用await包裹了权限判断：

const exporterExcel = boardExcelExporter(req, boardId, user); if ((await exporterExcel.canExport(user))) { // ... 构建并输出 Excel }

文件注释（models/exportExcel.js#L134-L138）还记录了另一个"未 await"教训：build(res)同样是 async 的，若不 await，其 rejection 会无声消失——浏览器等到一个永远不响应的导出请求，日志里却什么都没有。这说明"async 调用必须被 await"在 WeKan 中是贯穿权限检查与业务执行两个层面的硬约束。

回归测试设计：从源码定义反推全树扫描点

BFLABleed 修复后，WeKan 通过 tests/unawaitedAccessCheck.test.cjs 将这类漏洞变成结构性不可回归。该测试的设计思路非常值得借鉴。

第一步：动态读取"必须被 await"的检查清单

测试启动时读取server/authentication.js的源码，用正则提取所有async check*定义（tests/unawaitedAccessCheck.test.cjs#L42-L43）：

const authentication = read('server/authentication.js'); const ASYNC_CHECKS = [...authentication.matchAll(/^\s*async (check\w+)\s*\(/gm)].map(m => m[1]);

这意味着：以后任何检查函数被改成 async，无需修改本测试文件即可自动纳入约束范围。测试同时断言checkUserId、checkAdminOrCondition、checkBoardAccess、checkBoardWriteAccess、checkBoardAdmin都是 async，而同步的checkLoggedIn不应被列入（它就地抛出，不需要 await）。

第二步：扫描 server/models/packages/imports 全部调用点

测试遍历server、models、packages、imports四个目录下的所有 JS 文件（跳过node_modules、tests、_build和隐藏目录），先剥离注释，再逐行匹配Authentication.<checkName>(的调用模式（tests/unawaitedAccessCheck.test.cjs#L53-L76）：

若调用行前面紧邻await、return（含return !(...)等变体），或该行以async结尾（即 async 函数体内部的裸调用仍在模式之外），则判定为安全；
否则，记录该文件与行号，并断言不存在任何此类未 await 的调用。

从实际源码可以确认修复后的调用形态，例如 server/models/boards.js#L998 与 server/models/attachments.js#L66 都是await Authentication.checkBoardAccess(req.userId, paramBoardId);。测试还断言此类调用总数大于 100，证明扫描确实覆盖了全部 REST 路由的检查点，而非空跑。

第三步：对 ExcelBleed 的专项断言

针对导出链路，测试单独要求async canExport(的定义不少于 5 处（Excel/ExcelCard/PDF/Charts/普通导出等），并断言所有.canExport(调用都必须被 await（tests/unawaitedAccessCheck.test.cjs#L78-L85）。同时用正则确认 Excel 路由修复后的确切形态：if ((await exporterExcel.canExport(user)))。

第四步：自检（self-check）

测试还内置了一个"扫描器自检"用例（tests/unawaitedAccessCheck.test.cjs#L87-L92）：构造两行故意漏写 await 的样本代码，断言扫描器能识别出 2 处漏洞形态。这样即使扫描逻辑本身被误改，测试也会立刻暴露。

整个测试以普通 Node 脚本方式运行：

node tests/unawaitedAccessCheck.test.cjs

输出类似unawaitedAccessCheck: 5 tests passed。

与漏洞治理体系的联动：Hall of Fame 覆盖率台账

BFLABleed 的修复还牵动了一套更宏观的"已发布漏洞是否仍有回归测试"台账。WeKan 维护着*Bleed命名体系的安全漏洞索引，对应关系可在 docs/Security/Remediation/WeKan.md#L189-L232 的"Category ↔*Bleedcatalog"中查看——BFLABleed 被归入authz（broken access control）大类。

tests/securityRegressionCoverage.test.cjs#L304-L331 记录了关键治理事件：

22 → 20：BFLABleed 与 ExcelBleed（同为未 await 的异步访问检查）由 tests/unawaitedAccessCheck.test.cjs（2026-10-02）在全树范围兜底。

即：一旦某个漏洞被确认有了结构性回归测试，它就会从RECORDED（有漏洞但无测试）移入GUARDED（已有测试）清单；该测试还断言"缺口清单不得增长"（当前为 13），迫使任何新漏洞发布都必须立刻配套测试或书面原因。而 tests/hallOfFameProblemsCoverage.test.cjs#L110 则在 Hall of Fame 已知漏洞名列表中登记了BFLABleed，确保命名不被误拼、覆盖不被遗漏。

测试修复提交：Filter 测试与 Part 3/Part 4

03_2026-05-19.md第二段提到的"修复这些测试"对应发布说明中的 commit1b1b04d0。按 old-CHANGELOG/2026/05.md#L597-L601 的表述，该提交是"Fix tests. Added Filter test at part 4"的Part 3（另有 Part 4 提交24577ad2）。也就是说，BFLABleed 的修复同时要求配套的 Filter（筛选）相关测试同步通过，测试套件与安全修复是捆绑验收的。

这与其他测试会话记录共同构成 WeKan 测试体系的时间线：docs/Tests/01_2026-05-07.md记录 Playwright 16 个 spec、306/306 通过；docs/Tests/02_2026-05-20.md记录 5 套测试套件的运行修复；而docs/Tests/03_2026-05-19.md则是安全修复节点的记录。这些会话笔记与tests/目录下的真实测试互为印证。

总结：从一次越权漏洞到结构性防回归

回顾 BFLABleed 的完整闭环：

漏洞形态：async访问检查未await，Promise 的 truthy 语义使越权请求"静默放行"，影响 48 个 REST 端点；
修复手段：WeKan 9.23（commit8baa9124）为全部调用点补上await，server/authentication.js 成为唯一的权限判定来源；
防回归机制：tests/unawaitedAccessCheck.test.cjs 从源码定义动态提取 async 检查清单，全树扫描所有调用点并要求逐一 await，同时内置扫描器自检；
治理兜底：tests/securityRegressionCoverage.test.cjs 将 BFLABleed/ExcelBleed 移入GUARDED清单并锁死缺口数量，docs/Security/Remediation/WeKan.md 维护着完整的漏洞分类与防护点对照表。

对于任何构建 REST API 的团队，BFLABleed 都是一个极具代表性的警示："调用了一个 async 函数"与"执行了访问控制"是两件完全不同的事。让检查函数保持同步（就地抛错）或强制await，并将"遗漏 await"变成可被测试自动捕获的结构性缺陷，才是真正可靠的防线。