识别防护设备的目的
识别目标前置的 WAF、CDN 或云防护，目的是对齐测试预期而不是规避防护：确认防护存在后，需要调整测试节奏、把测试出口加入报备、必要时与防守方同步测试窗口。若在测试中频繁被拦截而仍按原强度继续，既会让进度停滞，也容易被判定为攻击流量而触发封禁。
基本信息
| 识别线索 | 响应头、拦截页面特征、行为差异 |
|---|---|
| 调整动作 | 降速、报备测试出口、确认测试窗口 |
| 记录要求 | 防护存在性与类型写入报告的环境说明 |
| 边界 | 不构造绕过请求，不测试防护设备本身 |
| 协作方式 | 与客户约定的对接口径同步拦截情况 |
典型使用场景
- 测试启动前确认前置防护，预判拦截概率与节奏
- 被拦截后判断是防护规则触发还是应用异常
- 与客户确认测试出口是否需要加入白名单
- 报告环境说明中标注防护架构，解释部分功能不可测的原因
- 复测时确认防护规则调整是否影响原有结论
确认要点
确认要点
# 1. 观察响应头与异常请求的响应特征
curl -sI https://target.example/ | findstr /I "server"
# 2. 触发一次明显异常参数，观察是否为统一拦截页面
# 3. 与客户确认防护架构与测试出口报备方式
# 4. 按约定节奏继续：降速、分批、避开高峰
# 5. 拦截情况记入日志，不尝试构造绕过线索读法
| 线索 | 含义 | 处置建议 |
|---|---|---|
| 统一拦截页 | 请求被边缘防护规则拦截 | 降速并同步客户，确认是否需加白 |
| 响应头特征 | 存在前置代理或 CDN | 记录架构，测试时注意源站与边缘差异 |
| 行为差异 | 同接口不同参数响应差异大 | 确认是否为规则拦截，避免误判为漏洞 |
| 连接重置 | 连接被直接断开 | 降低并发，避免被判定为攻击流量 |
发现防护设备后的正确动作是对齐预期：任何规避与绕过测试都不在评估范围内，除非单独授权并在规则中写明。
注意区分边缘防护拦截与应用自身报错：两者响应格式不同，混淆会把拦截页面误判为系统首页。