用途：识别 Web 应用中有状态接口的竞态条件漏洞，通过向同一接口并发发送相同请求，观察应用是否把多个同时到达的请求都当作唯一请求处理，从而发现 TOCTOU、优惠券/促销码重复使用、限额超发、双花和文件上传竞态。
适用场景：测试“先检查后操作”的接口（余额检查后扣款、优惠券有效后核销）；审计电商流程中的促销码、礼品卡、限量购买、推荐积分；检查敏感操作的限流（OTP 验证、密码重置、邮箱修改）；在漏洞赏金或渗透测试中测试金融或交易功能。
前置条件：已安装 curl；已安装 GNU parallel（apt install parallel 或 brew install parallel）；目标上准备两个测试账号，其中攻击者账号持有可核销资产（如优惠券码）。
输入变量：TARGET_URL（待测接口）、AUTH_TOKEN（Bearer 令牌或会话 Cookie）、REQUEST_BODY（POST 的 JSON 体）、CONCURRENCY（并发请求数）。
工作流程：先识别有状态操作，常见目标包括 POST /api/coupon/apply、/api/credits/spend、/api/order/place、/api/otp/verify、/api/transfer、/api/promo/redeem；再用 curl 定义单次请求函数，通过 seq 1 $CONCURRENCY | parallel -j $CONCURRENCY do_request {} 发送并发突发；随后统计返回成功（如 "success":true、"applied":true 或 200）的请求数，若多于一个则判定存在竞态；再调用账户状态读取接口核对服务端状态，确认是否出现多次核销、负余额或使用次数大于 1；最后按竞态类型评估影响。
影响分类：优惠券/促销码重复使用（TOCTOU）为中/高；双花（积分/余额）为高/严重；限额超发（限流）为中；文件上传竞态为中/高；OTP/令牌竞态为高/严重。
限制与失败模式：所有请求返回 429 说明被 IP 限流，可用 --interface 轮换源 IP 或在应用可信网络内测试；未安装 GNU parallel 可用 xargs -P 20 替代；若始终只有一个请求成功，说明服务端使用了原子数据库操作（SELECT FOR UPDATE、Redis SETNX），应记录为已缓解；响应相同但状态错误时需直接检查账户状态接口，部分服务端会返回缓存的成功响应；竞态窗口过小可将 CONCURRENCY 提高到 50，或改用 Burp Turbo Intruder 的 last-byte sync。
注意事项：竞态窗口通常只有几毫秒，GNU parallel 对 HTTP/1.1 目标时序对齐较好；HTTP/2 目标建议用 Burp Suite Turbo Intruder 的 race-single-packet-attack 模板实现单包同步，更可靠。始终使用专用测试账号和自己拥有的优惠券/积分，切勿针对真实用户资金测试。使用数据库级原子操作（如 UPDATE balances SET amount=amount-? WHERE amount>=?）的服务端属于正确缓解，单行受影响意味着竞态最多只成功一次。