haibo3434358 采样验证与归纳推断策略
核心原则：如果连续 N 个同类测试结果一致，说明是全局机制，不需要穷举。
什么时候用
发现以下情况时触发此策略：
- 100 个 API 需要测未授权访问
- 20 个 POST 接口需要测 CSRF
- 多个接口需要测 CORS
- 多个输入点需要测同一种注入
采样规则
| 接口总数 | 采样数量 | 连续一致即可结论 |
|---|---|---|
| < 10 | 全测 | - |
| 10-30 | 测 5-8 个 | 连续 5 个一致 |
| 30-100 | 测 8-10 个 | 连续 8 个一致 |
| > 100 | 测 10-15 个 | 连续 10 个一致 |
采样选取原则
不要随机选，要有代表性：
- 选不同模块的接口（如用户模块、订单模块、管理模块各挑几个）
- 选不同 HTTP 方法（GET、POST、PUT、DELETE 各挑）
- 选不同权限级别的接口（公开/用户/管理员各挑）
- 一定包含 /admin/ 或管理类接口（最容易遗漏鉴权的地方）
可归纳的测试方向
统一鉴权（最常用）
测 10 个接口去掉 Token → 全部 401/403
→ 结论：系统使用统一鉴权中间件，所有接口默认需要认证
→ 跳过其余接口的未授权测试
→ 但 /admin/ 类接口仍需单独测垂直越权
CSRF 防护
测 5 个 POST 接口 → 全部有 CSRF token 且去掉 token 请求失败
→ 结论：框架级 CSRF 防护（如 Spring Security / Django）
→ 跳过其余接口的 CSRF 测试
CORS 配置
测 5 个接口带 Origin: evil.com → 全部不反射
→ 结论：CORS 配置正确
→ 跳过其余
SQL 注入（ORM 框架）
确认技术栈是 Spring Data JPA / Django ORM / SQLAlchemy
测 3-5 个参数加单引号 → 全部无报错无异常
→ 结论：ORM 参数化查询，全局防护
→ 跳过常规 SQLi 测试（但仍关注原生 SQL 的接口，如搜索/报表）
不可归纳的测试方向
以下漏洞必须逐点测试，不能采样推断：
- IDOR 越权 — 每个接口的 ID 校验逻辑不同
- 业务逻辑漏洞 — 每个业务流程独特
- 文件上传 — 每个上传点的校验不同
- 支付逻辑 — 必须逐步验证
记录方式
采样验证后用 checklist_mark 记录结论时，在 detail 中说明：
checklist_mark(
vuln_type="未授权访问",
result="not_vuln",
detail="采样验证 10/10 个接口均需鉴权（统一中间件），跳过其余"
)