Strix 竞态条件（Race Condition）漏洞挖掘指南：从 TOCTOU 到并发不变量破坏的系统化测试方法

Strix 是开源 AI 渗透测试工具，其内置了面向具体漏洞类别的专项技能包（Skills）。race_conditions.md 正是其中定义"竞态条件测试"方法的技能文档，覆盖 TOCTOU（time-of-check to time-of-use）、双重消费、并发状态篡改等场景。本指南以此文档为主体，结合 Strix 仓库中技能的加载机制、扫描模式与证据校验实现，系统讲解如何对任意"读取—修改—写入"路径开展可复现、可验证的竞态漏洞挖掘与证明。读完你将掌握：识别并发攻击面的清单化方法、利用窗口制造与同步放大技术、以及避免误报并产出可信报告的完整闭环。

竞态条件为什么值得当作独立漏洞类别对待

并发缺陷引发的后果通常不是"崩溃"，而是重复的状态变更、配额绕过、资金滥用与越权错误。竞态攻击不需要精妙 payload，只需要同时发出多个本应互斥的合法请求，让服务端在两条并发路径上分别通过校验。因此 Strix 技能文档给出了一条基本原则：把每一条"读取—修改—写入"序列和每一个多步骤工作流都默认视为可被并发攻击的。

在 Strix 的实际执行中，这条技能不是静态文章，而是会被真实注入到 Agent 运行时上下文中。根据 skills 加载实现 与 load_skill 工具，技能文件存放在 strix/skills/<category>/<name>.md，validate_requested_skills 校验技能名、每个 Agent 最多携带 5 个技能，load_skills 解析 frontmatter 后把正文注入上下文。而 deep 扫描模式的技能定义 中，"Race conditions on all state-changing operations""TOCTOU vulnerabilities"被列为业务逻辑深测阶段的必测项——这印证了竞态测试在 Strix 方法论中的位置：不是边缘技巧，而是每个变更状态操作的默认检查项。

攻击面：什么代码值得并发测试

技能文档将竞态攻击面划分为四类。实践中应先在目标中完成一次"并发敏感性"盘点，把下列结构逐个标记为候选：

• Read-Modify-Write（读改写）：任何"先读值、再计算、后写回"的序列，且序列中缺少原子性或正确加锁。典型如 检查余额 → 扣款。
• Multi-Step Operations（多步骤操作）：校验 → 预留 → 提交 这类分阶段流程，各阶段之间存在时间缝隙。
• Cross-Service Workflows（跨服务工作流）：Saga 编排、异步任务与最终一致性系统——状态写入与发布之间天然存在可见性窗口。
• Rate Limits and Quotas（限流与配额）：只在边缘（如网关）实现、计数器非原子递增的限流控制。

高价值目标清单

以下对象只要出现"单次使用""每用户限额""唯一性"等字眼，就具备天然的高并发价值：

• 支付：授权（auth）/捕获（capture）/退款（refund）/作废（void）；积分、忠诚度点数、礼品卡。
• 优惠与折扣：一次性优惠码、叠加规则检查、每用户使用上限。
• 配额与限额：API 用量、库存预留、席位（seat）数量、投票次数。
• 认证流程：密码重置/OTP 消费、会话铸造、设备信任。
• 文件与对象存储：分片上传的 finalize/complete 步骤、版本写入、分享链接生成。
• 后台任务：导出/导入的 create/finalize 端点、任务取消/审批。
• GraphQL mutation 与批量操作、WebSocket 动作。

侦察：先找竞态窗口，再找信号

识别竞态窗口

在开始并发轰炸之前，先用代码走读与流量分析定位窗口存在的位置：

1. 寻找显式序列表述：文档或注释中的"先查余额再扣款""验证优惠券后应用""检查库存再购买"。
2. 留意乐观并发标记：ETag/If-Match、version 字段、updatedAt 检查。它们的存在本身就说明开发者意识到了并发，也常常是绕过点。
3. 检查幂等键支持：作用域（按路径还是按主体）、TTL、持久化介质（缓存还是数据库）。作用域过窄或仅存内存的幂等键都可以绕过。
4. 绘制跨服务步骤：状态何时写入、何时发布？重试与补偿机制是什么？——这决定了窗口的可利用宽度。

竞态信号

运行期若观察到以下现象，说明存在值得深挖的竞态窗口：

• 顺序请求失败，但并行请求成功；
• 出现重复行、负数计数器、超发量或不一致的聚合结果；
• 并行与顺序请求的响应形态/耗时存在明显差异；
• 审计日志乱序、同一意图出现多个 2xx、相关性 ID（correlation ID）缺失或重复。

关键漏洞类型与利用手法

技能文档将竞态漏洞细分为七类，每类的失败点与攻击手法各不相同：

请求同步（Request Synchronization）

利用窗口的前提是"真正同时到达"：

• 用 HTTP/2 多路复用在已预热连接上同时发送大量请求（HTTP/1.1 连接队头阻塞会稀释并发精度）；
• last-byte 同步：把请求保持打开、缓存到只剩最后字节，再同时释放，使服务端在同一时刻收到完整请求；
• 连接预热：预先建立会话、Cookie 与 TLS 握手，消除网络抖动对对齐的影响。

幂等与去重绕过（Idempotency and Dedup Bypass）

• 当幂等键作用域不充分时，在多个不同主体/路径间复用同一个幂等键；
• 在幂等存储写入之前命中端点——利用"先入缓存后提交"（cache-before-commit）的窗口；
• 利用应用层去重只丢弃响应、副作用仍发生的缺陷（如邮件、积分照发）。

原子性缺口（Atomicity Gaps）

• 丢失更新（Lost update）：读改写式的自增未使用原子数据库语句；
• 两阶段工作流不完整：验证完成前成功已被提交；
• 唯一性检查在唯一索引/upsert 之外完成：高负载下产生重复记录——正确做法是唯一索引 + ON CONFLICT/UPSERT，而非插入前的存在性检查。

跨服务竞态（Cross-Service Races）

• Saga/补偿时序缺口：执行补偿操作时未阻止原始成功路径继续生效；
• 最终一致性窗口：在服务 A 的写入对服务 B 可见之前行动；
• 重试风暴：at-least-once 投递 + 无幂等消费者 → 重复副作用。

限流与配额绕过（Rate Limits and Quotas）

• 基于 per-IP / per-connection 的强制：用多个 IP/会话即可绕过；
• 计数器更新非原子或分片不一致：在计数器传播前发送突发流量。

乐观并发绕过（Optimistic Concurrency Evasion）

• 在 ETag/If-Match 为可选的地方省略它们；若服务端忽略陈旧版本则提交旧版本；
• 版本字段只在部分代码路径被校验（例如 GraphQL 与 REST 行为不一致）。

数据库隔离漏洞（Database Isolation）

• 利用 READ COMMITTED/REPEATABLE READ 异常：幻读、非可串行化序列；
• Upsert 竞态：用唯一索引 + 正确的 ON CONFLICT/UPSERT 才是正解，naive 存在性检查会被并发绕过；
• 锁粒度问题：行锁 vs 表锁；仅存在于进程内的应用锁在水平扩展后形同虚设。

分布式锁缺陷（Distributed Locks）

• Redis 锁未用 NX/EX 原子选项、缺少 fencing token 时会出现多个赢家；
• 锁仅存在单节点的内存中——直接打到其他节点/区域即可绕过。

绕过技巧与特殊上下文

通用绕过技巧

• 分散到不同 IP、会话与用户账户，规避 per-entity 节流；
• 切换方法/内容类型/端点，让同一状态变更经由不同代码路径触发；
• 主动制造超时以诱发重试，从而产生重复副作用；
• 用大 payload、慢端点拖慢目标，人为加宽竞态窗口。

特殊上下文要点

• GraphQL：并行 mutation 与批量操作可能绕过 per-mutation 守卫；必须在 resolver 层实现幂等与原子性；持久化查询（persisted queries）与别名可把多次状态变更隐藏在一个请求里。
• WebSocket：仅握手鉴权是不够的，每条消息的鉴权与幂等都必须成立；并发 emit 会造成重复。
• 文件与存储：对分片上传并行调用 finalize/complete 可能产生重复或损坏对象；并发复用预签名 URL。
• 认证流程：一次性令牌（重置码、magic link）被并发消费、铸造多个会话——必须验证"消费"这一步是原子的。

漏洞链组合：竞态作为放大器

单个竞态往往只是起点，技能文档给出了四条典型的链式路线：

• 竞态 + 业务逻辑：违反不变量（双重退款、限额切片）；
• 竞态 + IDOR：在属主校验完成前修改/读取他人资源；
• 竞态 + CSRF：让受害者触发并行操作以放大影响；
• 竞态 + 缓存：并发变更后陈旧缓存重新供应特权状态。

这与 Strix 的 deep 模式中"把单个漏洞当作 pivot 点、跨组件组合成端到端利用链"的总体策略一致（见 deep.md 的 Vulnerability Chaining 阶段）。同类的跨类别指引还可在 business_logic.md 中找到——其"Concurrency and Idempotency"小节与竞态技能互为补充。

测试方法论：从建模到并发执行的七步流程

技能文档规定了一套可复现的七步方法，核心是先单发建立基线、再并发观察增量：

1. 建立不变量模型（Model invariants）：为每个工作流定义价值守恒、唯一性、最大值等约束。
2. 识别读写位置（Identify reads/writes）：确定读写在何处发生（服务、数据库、缓存）。
3. 基线（Baseline）：先用单请求确立预期行为。
4. 并发请求（Concurrent requests）：以完全相同输入发出并行请求，观察与基线的增量。
5. 放大与同步（Scale and synchronize）：提高并行度、使用 HTTP/2、用 last-byte 同步对齐时序。
6. 跨渠道（Cross-channel）：同时覆盖 Web、API、GraphQL、WebSocket。
7. 确认持久性（Confirm durability）：验证状态变更确实持久化且可复现。

验证与误报控制：只报告可证明的发现

验证标准（Validation）

一条竞态漏洞要成立，必须全部满足：

1. 单请求被拒绝，但 N 个并发请求中"本应只有 1 个成功"的场景下却成功了多个；
2. 已证明持久化状态变更（账本条目、库存数量、角色/权限标志）；
3. 在受控同步（HTTP/2、last-byte sync）下可复现，多次运行稳定成立；
4. 如适用，REST 与 GraphQL 等多渠道均有证据；
5. 附带前后状态对比与精确的请求集合。

误报清单（False Positives）

以下情况不应上报为竞态漏洞：

• 真正幂等的操作，且 ETag/version 检查或唯一约束被强制执行；
• 可串行化事务，或正确的咨询锁（advisory lock）/队列；
• 仅视觉异常、无持久状态变更的"幻影故障"；
• 用原子计数器拒绝多余请求的限流。

这些证据纪律与 Strix 的全局闭环纪律一脉相承。Strix 的报表工具在提交漏洞时强制要求 counterevidence（反证）字段非空（见 reporting/tool.py），counterevidence.md 进一步规定了三种收尾状态：confirmed（有可工作的 PoC）、ruled_out（能点名具体控制项及其位置与作用路径）、open_proof_gap（证据缺口，必须记录跟进而不是静默关闭）。竞态发现若只在多路并发下偶现，恰恰是最容易掉进"悄悄关闭"陷阱的候选。

影响评估（Impact）

一个确认的竞态漏洞通常落在以下四类影响中，评定严重性时应按实际可证明的影响定级（Strix 的 severity_calibration.md 要求先证明可达性再做定级）：

• 经济损失：双重消费、积分/退款超发；
• 策略/限额绕过：配额、一次性令牌、席位数量；
• 数据完整性破坏与审计链路不一致；
• 并发更新引发的权限或角色错误。

实战要点（Pro Tips）

技能文档收尾的十条建议直接决定竞态测试的成败，浓缩如下：

1. 优先 HTTP/2 + 预热连接，必要时用 last-byte 同步保证精度；
2. 从 N=5–20 的小并行度起步再逐步放大——噪声过大反而会掩盖窗口；
3. 优先瞄准读改写代码路径与带幂等键的端点；
4. 对比 REST vs GraphQL vs WebSocket——它们的防护往往不一致；
5. 关注跨服务缺口（队列、任务、webhook）与重试语义；
6. 检查唯一约束与 upsert 的实际使用，警惕"插入前检查"式实现；
7. 用 correlation ID 与日志证明并发交错确实发生；
8. 通过服务器负载或慢后端依赖加宽窗口；
9. 在接近生产的延迟下验证——部分竞态只在真实负载下出现；
10. 沉淀最小可复现的请求集合，证明持久影响。

对于可复现的请求链，还可以参考 Strix 的 hurl 回归测试技能：Hurl 以文件描述精确的请求序列、捕获值与断言，可用于记录"并发前后端到端请求链"并作为可回放的证据载体。

小结

并发安全不是某一个函数的属性，而是每一条会变更状态的路径的属性。只要存在任何一条缺少原子性、正确隔离或幂等性的路径，并行的合法请求终将打破不变量。把"读改写序列默认视为可并发攻击"，按本指南的七步方法建模、并发、同步、多渠道验证、确认持久性，并在 counterevidence 纪律下收尾——你就能把"也许存在竞态"的猜测，变成附带完整证据集的确定性发现。

使用 Strix 执行此类测试时，可参考 penetration-testing-with-strix 技能 中通过 strix -n -t <target> 发起扫描的方式，并将本竞态技能通过 skills="race_conditions,..." 注入负责并发专项的子 Agent；技能加载与注入机制详见 strix/skills/init.py。