竞态条件

先搞清楚要解决什么问题

竞态条件（Race Condition）并不是代码里的边角案例。当系统的安全性或业务逻辑依赖于"同一资源只能被处理一次"时，一旦缺少原子性或同步控制，攻击者就能利用并发执行制造非预期状态。

最典型的是 TOCTOU（Time-of-Check to Time-of-Use）：系统在某个时刻检查了条件，但在实际使用结果之前，状态已经发生变化。常见后果包括：

• 账户余额篡改：同时发起多次提现或转账，只扣款一次
• 优惠券 / 促销码重用：单次使用的兑换码被并发复用
• 令牌验证绕过：一次性令牌在失效前被多次使用
• 资源分配超限：库存、连接、内存等有限资源被超额分配

这类问题在漏洞赏金中往往因为难以稳定复现而被忽略，但它的影响可能是直接的经济损失或权限提升。

这个技能如何工作

该技能的核心是一套可执行的检测清单，围绕"识别高风险功能 → 构造并发请求 → 观察状态异常 → 评估影响"展开。

1. 锁定目标功能：优先关注处理状态变更、有限资源或关键操作的功能，例如资金交易、库存分配、积分兑换、密码重置、带速率限制的 API 端点。
2. 基线行为分析：记录正常的请求 / 响应模式和事务流程，确定哪个步骤是关键的"状态变更点"。
3. 并发请求探测：使用 Burp Suite Turbo Intruder 或 Repeater 的多线程能力，同时发送 10～100 个相同请求。更高阶的做法是利用 HTTP/2 / HTTP/3 的多路复用实现微秒级并发，或采用 Last-Byte-Sync 技术在多个连接上几乎同时提交请求的最后一部分。
4. 结果比对与重复执行：观察应用状态是否出现异常，并通过多次重试最大化命中概率。

技能还覆盖了特定场景的测试路径：

• 速率限制与 CAPTCHA 竞态：跨会话 / IP 并发发送登录或 OTP 请求，探测共享计数器的行为
• 会话处理绕过：当框架（如 PHP 默认 session）对 session 文件加锁时，可通过获取多个有效 session ID 并分别分配给并发请求来绕过锁
• 数据库隔离级别：测试不同隔离级别下的并发行为，例如 PostgreSQL 或 MySQL/MariaDB 下的事务窗口
• 云与 Serverless 竞态：针对 AWS Lambda、GCP Cloud Functions 等，验证事件被并行处理的可能性
• GraphQL 与 gRPC：利用 GraphQL 批量变更绕过常规 CSRF 或速率限制控制；在 gRPC 中在后端提交状态前并发打开多个 SendMsg 帧

适用边界与注意点

竞态条件测试对网络延迟非常敏感。如果测试基础设施与目标服务器距离较远，并发请求的时间偏差可能足以让请求落入不同的处理窗口，导致测试结果不可信。使用与目标同区域或同云厂商的 VPS 可以显著提升命中率。

同时，结果验证需要仔细区分"应用层面异常"与"网络层抖动"。建议结合分布式追踪（如 OpenTelemetry）和重复调用指标来确认竞态是否真实存在，而不是单次请求超时或重试造成的假象。

从防御角度看，现代缓解手段包括使用原子的 UPSERT / ON CONFLICT 语句、实现 Idempotency-Key 头配合短 TTL 存储，以及跨服务资源锁。如果目标系统已经部署了这些机制，相应的竞态窗口可能会显著缩小甚至消失，需要据此调整测试策略。