代码审计里的缓存投毒：六个检查点

缓存欺骗利用的是路径后缀，让需要登录的页面被当成静态资源缓存下来

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

先说结论

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

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

检查点一：入口

响应没设 Vary 时，缓存会把带特殊请求头的那一份存下来发给所有用户，而且很难被察觉。

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

检查点二：危险点

CDN 通常只缓存 200 与 301，一旦命中，TTL 内所有访客拿到的是同一份响应，包括登录后的页面。

检查点三：校验逻辑

反代信任 X-Forwarded-Host 时，页面里的绝对链接与跳转目标都能被改写，可能直接指向外部站点。

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

这个问题的几个审计细节

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

• 缓存欺骗利用的是路径后缀，让需要登录的页面被当成静态资源缓存下来

检查点四到六

缓存欺骗利用的是路径后缀，让需要登录的页面被当成静态资源缓存下来。

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

再补充几点

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

• 缓存键不包含某个请求头，而响应内容又受这个头影响，就具备了投毒条件
• 清一次缓存只能救一时，键的设计不改还会被重新投毒，把受影响的头并进缓存键才是根治
• 以为上了 HTTPS 就不会被投毒，这跟传输层加密无关
• 把带 Set-Cookie 的响应也缓存了，登录态互相串
• 只在源站加了头，CDN 层的缓存规则没有同步

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