客户发来一句话，说你们这个站是 ThinkPHP，网上爆过好几个高危漏洞，让我们出份检测报告。这时候最不该做的，就是搜一个扫描器下来对着站打一遍。

先把版本号查清楚

composer.json 里能看到框架版本，vendor 下 topthink 的目录名也带着线索。ThinkPHP 3、5.0、5.1、6、8 是完全不同的代码基线，安全公告都按版本区间发布。版本没确认就去打补丁，很容易打错分支，或者以为修了其实没修。

对着官方公告逐条核

框架官方仓库的发布记录和安全公告是唯一可信来源，看自己版本落在哪些条目里。第三方文章经常把 5.0 的问题写到 5.1 头上，照着改反而改坏。把命中的条目列成清单，逐条到代码里确认对应位置。

几个必查的配置项

  • 调试模式是否关闭，开着会泄露路径、SQL 和环境变量
  • 入口文件是否只暴露 public 目录，application 和 vendor 不能直接访问
  • runtime 日志目录、上传目录是否禁止执行 PHP
  • 数据库账号是否只给了业务库权限，别用 root
  • 是否残留测试入口和没删掉的安装目录

上传目录是重灾区。Nginx 里给 uploads 路径加一条规则，把以 php 结尾的请求直接拒绝，比事后清理一句话木马省事得多。日志目录同理，能写不能执行。

日志里也有信号。runtime 目录如果出现大量来自同一 IP 的异常请求记录，或者 uploads 里冒出 php 文件，基本能确定已经被扫过。把这两处接进监控，比事后翻报告快得多。第三方插件和主题也是常见入口，装之前看一眼最近一次更新。

扫描器能做什么不能做什么

开源和商业的 Web 扫描器确实存在，能覆盖一批通用问题，但它们靠规则匹配，对框架特有的反序列化、路由绕过基本无能为力，误报也不少。真要用，只在自己有授权的资产上跑，跑完人工复核每一条结果，别拿报告直接交差。

更实际的做法是把 composer 依赖升到修复版本，前面挂一层 WAF 拦明显特征，再定期比对官方公告。这几件事做完，比抱着扫描器报告安心。