关于漏洞验证的五个误解

证据要包含时间与所用账号，否则开发无法复现，工单会来回三次以上，模板化能省一半沟通

下面五条，每条都能对应一个真实的事故模式。

先说结论

误解的共同点是：把「降低概率」当成「消除风险」。

• 误解一：有 WAF 就安全
• 误解二：内网系统不用管
• 误解三：修完就没事了
• 误解四：低危可以先放着
• 误解五：加密了就安全了

误解一：有防护设备就安全

同一个响应被 CDN 缓存后两个账号看到同一份数据，很容易被误判成越权，换个节点结论就变。

WAF 挡的是已知模式，绕过的成本往往是「改个编码」级别。它能降噪，不能当唯一防线。

误解二：内网不用管

统一错误页会让 200 状态码掩盖失败，判断要看响应体的差异而不是状态码，也可能被前置层拦了。

内网的前提是「边界真的存在」。一旦有一台机器被钓鱼，内网就是平的。

误解三：修完就没事了

看到报错信息就定为高危，没有验证可利用性

修复要覆盖：同一入口的其它路径、同类代码的其它位置、以及历史数据。

这个问题的几个常见误判

实际评估时最容易被带偏的几条：

• 换一个更低权限的账号复现一次，能排除「本来就该看到」这类误报，这一步不能省
• CVSS 只描述技术影响，环境补偿比如有无 WAF、数据敏感度要单独写一段

误解四与五

多个低危串起来常常就是一条完整链路：信息泄露、越权、拿后台。加密解决的是机密性，解决不了「密钥在代码里」和「加密了但没验签」。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 验证的目标是证明前置条件成立，而不是把影响做到最大，后者属于越界
• 用管理员账号测越权，结论必然失真
• 截图只截结果，没有请求内容，开发不认

安全里最贵的一句话是「应该没问题吧」。