必须立即排查ThinkPHP高危漏洞：先确认精确版本号，再运行composer audit --lock，接着人工验证RCE、SQL注入和Cookie HttpOnly缺失，然后用TPscan深度扫描，最后检查composer.lock中overtrue/wechat等危险组件。
公司项目用了ThinkPHP框架，必须立即排查是否暴露远程代码执行、SQL注入、Cookie未设HttpOnly等高危漏洞，不能依赖“好像没出事”这种侥幸判断。
第一步：确认ThinkPHP具体版本号
打开项目根目录下的composer.json，查找"topthink/framework"或"topthink/thinkphp"字段，记录精确版本号（如"5.1.36"或"6.0.11"）；若无composer.json，直接查看thinkphp/library/think/App.php顶部注释里的@version行。
版本号不准会导致后续所有检测失效——比如把5.1.37误判为5.1.36，就会漏掉已修复的RCE漏洞。
第二步：运行Composer内置安全审计
确保PHP版本≥8.1，执行：composer audit --lock。
该命令会自动比对composer.lock中每个组件的版本与Packagist官方安全数据库，直接输出CVE编号、影响范围和严重等级。若提示Command "audit" is not defined，先运行composer self-update升级Composer到最新版。
【必须检查composer.lock文件是否真实存在且未被手动修改过】——有人为“提速”删掉lock文件或用composer install --ignore-platform-reqs跳过校验，audit将完全失效。
第三步：人工验证三类高频漏洞点
方法一：远程代码执行（RCE）快速探测
在浏览器访问以下URL（替换your-domain.com为实际域名）：http://your-domain.com/index.php?s=index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=1
如果页面返回PHP配置信息，说明5.0.x/5.1.x版本存在未修复RCE漏洞；返回404或空白页不等于安全，需继续验证其他入口。
方法二：SQL注入风险代码扫描
全局搜索项目代码中出现where(、query(、execute(、Db::name(后紧跟$_GET或$_POST变量的写法，例如：where("id=".$_GET['id'])——这种拼接方式100%可被利用，必须替换为参数绑定语法where('id', input('id'))。
方法三：Cookie HttpOnly缺失检查
用浏览器开发者工具（Network → 任意请求 → Response Headers）查看Set-Cookie头是否包含HttpOnly字段。若缺失，登录态Cookie可能被XSS脚本窃取——ThinkPHP 5.1默认不开启，必须手动配置'httponly'=>true。
第四步：使用TPscan-master进行深度扫描
① 下载工具：git clone https://github.com/beicheng123/TPscan.git
② 进入目录：cd TPscan
③ 安装依赖：pip3 install -r requirements.txt
④ 执行扫描：python3 tp-scan.py -u http://your-domain.com --level 3
⑤ 查看结果：output/目录下生成的HTML报告会标出RCE、文件包含、未授权访问等漏洞路径及PoC验证链接。
注意：扫描时需关闭WAF或临时放行/index.php?s=类请求，否则会漏报；【禁止在生产环境直接运行--exploit参数】——该参数会尝试写入Webshell，触发安全告警甚至被拦截。
第五步：检查composer.lock中的危险组件
打开composer.lock文件，搜索"name":字段，逐行核对以下高危组件是否存在：
• "overtrue/wechat"（v4.2.0以下存在RCE）
• "league/flysystem"（v1.0.70以下存在反序列化）
• "monolog/monolog"（v1.25.3以下存在日志注入）
发现即停，立刻执行composer update 包名升级到已修复版本。
这一步不能跳过——ThinkPHP本身无漏洞，但你项目里引入的第三方包可能带毒。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
