代码审计里的漏洞验证：六个检查点

CVSS 只描述技术影响，环境补偿比如有无 WAF、数据敏感度要单独写一段

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

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

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

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

检查点三：校验逻辑

换一个更低权限的账号复现一次，能排除「本来就该看到」这类误报，这一步不能省。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• CVSS 只描述技术影响，环境补偿比如有无 WAF、数据敏感度要单独写一段

检查点四到六

CVSS 只描述技术影响，环境补偿比如有无 WAF、数据敏感度要单独写一段。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

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

• 验证的目标是证明前置条件成立，而不是把影响做到最大，后者属于越界
• 证据要包含时间与所用账号，否则开发无法复现，工单会来回三次以上，模板化能省一半沟通
• 看到报错信息就定为高危，没有验证可利用性
• 用管理员账号测越权，结论必然失真
• 截图只截结果，没有请求内容，开发不认

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。