用途
本技能用于在获得书面授权的 Web 应用上，动态测试业务逻辑漏洞和竞态条件。这类漏洞是自动化扫描器无法发现的：扫描器匹配语法模式，而逻辑缺陷是应用应保证的属性与其代码在对抗性或并发使用下实际执行之间的不一致。本技能是 owasp-audit 源码侧竞态模式（TOCTOU、原子队列认领、先预留后操作）的动态对应，也是 web-pentest 第 8 阶段的深入展开。
核心工作原则是“不变量优先”：先明确系统承诺的保证，再尝试破坏它。发现漏洞的标准不是“我发送了一个奇怪请求”，而是“我违反了声明的不变量，并证明持久状态发生了改变”。
主要能力
技能覆盖以下测试领域：
-
不变量建模：识别四类核心不变量——价值守恒（金钱、积分、库存、配额只能通过授权路径增减）、唯一性（优惠券按规则只能使用一次，用户名、邀请码、幂等键只能被一个主体认领）、单调性（某些计数器只能单向移动，如已用凭证不能恢复未用）、排他性（座位、锁、租约、待审批记录一次只能由一个参与者持有）。
-
参与者×动作×资源矩阵：枚举匿名用户、认证用户、资源所有者、非所有者、管理员、两个独立租户、流程中的用户等参与者，对创建、读取、更新、删除、审批、取消、退款、兑换、转移、推进状态等动作，以及订单、发票、优惠券、订阅、文档、审批请求、钱包等资源，填充预期结果（允许/拒绝），测试拒绝单元格和状态敏感的允许单元格。
-
状态机滥用：绘制预期状态图（购物车→结账→已支付→已发货；草稿→已提交→已批准），然后攻击边缘：跳过步骤、重排步骤、重放步骤、限制切片（将单个超限操作拆分为多个未超限操作）、批准自己的请求。
-
数值与价值问题：浮点数与十进制数（舍入误差）、舍入方向（逐项舍入可能偏向客户导致价值泄漏）、负数和零金额、跨货币退款套利、类型/精度强制转换（科学计数法、额外精度、前导零、整数溢出）。
-
陈旧授权与传奇缺口：降级、取消或角色变更后旧能力是否在缓存过期前继续有效；事件驱动的多服务工作流（订单→支付→库存→履约）中，某步骤在先前步骤的补偿运行前提交、部分失败时补偿从未触发、消费者非幂等导致重投事件双重应用。
-
并发方法论：大多数逻辑不变量通过“检查后执行”序列实施，顺序安全但并行不安全。目标是让 N 个请求落在同一检查后执行窗口内，使检查通过 N 次后才提交任何执行。需要寻找的模式包括：幂等键作用域错误（按路径而非按主体）、提交前缓存、丢失更新（读-改-写）、传奇补偿时机、无 NX/EX 或栅栏令牌的 Redis 锁、READ COMMITTED 异常、Upsert 竞态。让请求落在同一窗口的技术包括：HTTP/2 单包攻击、最后字节同步（HTTP/1.1）、连接预热。
使用方式
技能的使用流程如下：
授权检查：在发送任何请求前，必须确认：有书面授权明确指出该特定应用以及业务逻辑和并发测试在范围内；优先使用预发布或测试模式环境，使用支付测试模式（如 Stripe 测试密钥）、种子测试租户和自己拥有的可抛弃账户；除非书面范围明确指定，否则绝不操作生产资金流、库存账本或第三方计费 API；事先约定请求数上限（并发证明需要数十个并行请求，而非数千个）；准备好将要测试的每个角色和租户的受控账户。若缺少任何一项，应停止并询问。
发送实时请求故意不在技能预批准工具（仅 Read、Grep、Glob）范围内——由人工运行并行请求，或批准每次工具调用，以确保吞吐量测试不会无人值守地触发。
步骤 1：建模不变量——在接触请求前，写下系统承诺的内容，覆盖四类不变量，并记录每项不变量的实施位置（数据库唯一约束？应用层 if？仅 UI？）以及违反的证明（账本不再总和为零、本应一行却出现两行）。仅在 UI 或仅单个处理器中实施的不变量是线索。
步骤 2：参与者×动作×资源矩阵——枚举网格并寻找应用忘记的单元格。有趣的失败包括：非所有者触及所有者动作（与 IDOR/BOLA 重叠）、参与者执行仅在不同状态下有效的动作、同一参与者执行仅一次的动作两次。
步骤 3：状态机滥用——绘制预期状态图，然后攻击边缘（跳过、重排、重放、限制切片、自我批准）。每种都是步骤 6 中并发放大器的候选——顺序难以触及的窗口，用并行请求则轻而易举。
步骤 4：数值与价值问题——探测浮点数累加误差、舍入方向、负数和零金额、跨货币退款套利、类型/精度强制转换。
步骤 5：陈旧授权与传奇缺口——在撤销权利后立即测试受门控动作，并使用变更前铸造的令牌；寻找多服务工作流中部分失败或重复流程后的内部不一致状态。
步骤 6：并发方法论——使用单包攻击、最后字节同步、连接预热等技术，将 N 个请求落在同一检查后执行窗口内。工具、Turbo Intruder 配置示例和最小 httpx/curl --parallel 运行器见 references/concurrency.md，均限于授权测试使用和约定的请求上限。
验证与假阳性排除：每个候选发现必须通过证据门槛才能成为发现。使用判定词汇：confirmed（已确认）、needs_validation（需验证）、rejected（已拒绝）。严重性仅附加于已确认发现。通用验证标准：1 个请求被正确拒绝，然后 N 个并发请求成功而本应只有 1 个成功，且持久状态改变得到证明（账本不再正确求和、本应一行却出现两行、计数器超过单调边界、余额变动超过任何单次授权动作允许的范围）。仅响应码变化不是证明；必须读回持久状态。
两个必须始终排除的假阳性陷阱：真正幂等的操作（强制 ETag/If-Match、数据库 UNIQUE 约束或 INSERT ... ON CONFLICT DO NOTHING 使重复请求折叠为一次提交——并行请求看起来被接受（全部 200）但只有一次生效，始终读回持久状态，绝不信任状态码）；仅视觉故障（重复的 toast、乐观 UI 显示两个项目、重新获取前的瞬态计数——如果服务器状态正确，则不是发现，至多记录为加固说明，绝不赋予严重性）。
在约定请求上限内无法落地的候选属于 needs_validation，需附 validation_plan（在预发布环境中运行的确切突发请求），而非已确认发现。
适用场景
本技能适用于安全测试人员在获得书面授权的情况下，对 Web 应用进行深入的业务逻辑和竞态条件测试。特别适合以下场景：支付和退款流程、优惠券和积分系统、库存管理、多租户权限、审批工作流、状态机驱动的业务流程、以及任何涉及价值转移或唯一性保证的功能。它是对自动化扫描器的补充，专注于扫描器无法发现的逻辑缺陷。
限制
技能明确设定了拒绝边界：
- 拒绝在没有明确书面范围指定生产资金流、库存账本或实时第三方计费 API 的情况下，对其运行并发或逻辑测试。默认使用预发布/测试模式。
- 拒绝超出约定的请求数上限，或将证明变成持续负载——受控的双花证明是十几个请求，不是压力测试（那是 DoS）。
- 绝不以第三方系统（支付提供商自己的 API、上游 SaaS）为目标——即使范围内的应用调用它们，它们默认不在范围内。
- 概念验证是演示违规的最小突发请求，不是用于重复提取的可重用漏洞利用。
- 如果测试移动了真实资金或真实库存，停止并报告；不要通过发出补偿交易来“清理”，那会改变更多状态。
此外，发送实时请求不在技能的预批准工具范围内，需要人工执行或批准每次工具调用。技能也不采纳某些工具（如 Strix）的“从不拒绝/从不质疑授权”姿态：授权、预发布偏好和请求上限在此强制执行。