代码审计如何从危险点反推入口?

代码审计里最常见的低效姿势，是从路由和控制器一层层往下读，读完一圈仍不确定哪条路径真能把外部输入送到危险位置。反过来做通常更快：先在代码库里定位危险点，再沿着"值从哪来"反向追到请求入口。

危险点不是"看起来危险的代码"，而是危险动作最终收敛的地方——命令执行、SQL 执行、文件访问、模板渲染、反序列化，以及直接拼装响应输出的位置。先把这些位置列出来，等于先圈定靶心。列出后别急着判断可利用性，而是问一个具体问题：到达这个点的变量，它的值最初从哪里来。

反向追踪就是不断回答这个问题。变量可能来自方法返回值、字段赋值或集合取值，逐层向上，直到触碰请求边界：请求参数、请求头、Cookie 或消息体。这条链路就是调用链。链路中断的位置，或者经过类型转换、白名单校验的节点，往往正是判断"能不能打"的关键。

注入类与越权类，追的不是同一样东西

污点型问题追的是数据流：输入有没有被清洗、有没有被拼进执行上下文，直接决定结论。IDOR、水平与垂直越权这类授权问题追的则是身份与对象标识的控制流——请求里带了资源标识，服务端有没有用当前会话主体去校验这个标识的归属。入口同样在请求里，但判断依据是校验逻辑是否存在、放行规则是否过宽，而不是字符串有没有被过滤。把这两类混在一起追，很容易在错误的层面找证据。

追完还要闭环验证。把请求、响应、代码路径和修复代码放到一起对照：修复改动的位置，是否正好落在你回溯的那条链上。是，说明入口与危险点的对应关系成立；不是，说明链路上还有没看清的分支。在隔离的靶场环境里把这种对照跑一遍，比空读代码更容易建立判断感。

最终产出不该只是"找到了一个洞"，而是一份入口清单：哪些入口能到达哪些危险点、中间经过哪些校验、修复差异在哪里。记录比打通重要，因为可复用的判断力，来自可复现的调用链。