靶场练习之外的审计能力缺口

在靶场里定位一个命令执行点，通常很快：模块名已经说明了漏洞类别，页面直接给出入口参数，危险函数就那么几行。换到一份没有标注的真实业务代码，同样的动作可能耗去大量时间，结论还经常停在“看起来可疑，但确认不了可达”。这个落差不是熟练度问题，而是两类任务的信息结构不同——靶场把审计中最难的部分替你完成了。

靶场替你省略的三件事

一个漏洞场景要成立，需要范围、类型和对照答案。靶场在提供练习环境的同时，也把这三样一并给了：模块列表圈定了可疑区域，页面标题点明了风险类别，修复模块提供了标准答案。真实审计里，这三样都得自己建立。审计者面对的往往是规模可观的代码库、多层框架封装和一套没人完整读过的配置，第一步不是找 sink，而是判断哪些代码在运行时真的会被执行。

缺口一：可达性

靶场里请求直达控制器，调用链是通的；真实系统里大量代码被网关拦截、被特性开关关闭、被前置校验短路，或者参数在进入业务层之前已被框架改写。静态扫描报出的危险函数调用，很大比例落在不可达分支或已受控路径上。把“存在危险调用”和“该调用可被外部输入触达”区分开，才是审计判断的起点。

缺口二：配置与代码的耦合

这一层更隐蔽。以越权为例，控制器本身的写法可能完全合规，但安全配置里的放行规则一旦过宽，这条路径就变成未授权访问。原文提到的修复提交里，越权控制器和安全配置是并列出现的项，恰好说明这类问题无法只读一个文件就下结论——路由、拦截器、放行规则必须合在一起看。靶场把这些要素摆在同一页，真实项目里它们分散在不同模块、不同维护人手里。

缺口三：结论的可复核性

练习的目标常常是“打通”，而审计的交付物是一条可复核的链路：输入从哪来、经过哪些处理、在什么条件下到达危险操作、影响范围多大、修复该落在哪一层。只记录请求和结果，换一个人无法复现你的判断过程，这条经验也就无法复用。

补这些缺口，方向不是多刷几个靶场，而是改变使用方式。同一套环境，可以试着遮住模块名，只从代码和路由入手推断漏洞类型，再用修复模块当参考答案核对；也可以反过来，在开源项目里做无标注审计，把靶场的修复对照当作校准基准。原文提到的用本地静态规则验证检测效果，同样适合放在这一步——重点不是命中多少条，而是命中项里有多少真正可达。

靶场提供的是有答案的对照组。审计能力恰恰体现在没有对照组的时候，仍能对可达性、配置耦合和结论边界作出判断。