Linux下ThinkPHP安全审计核心是四条主线：查入口错误回显确认APP_DEBUG状态与架构版本，验runtime日志路径是否可直接访问，审中间件权限逻辑是否真实生效，扫SQL拼接、文件操作、反序列化等危险代码模式。
Linux下做ThinkPHP安全审计，核心是结合系统环境与框架特性，从可访问路径、配置风险、日志暴露、代码漏洞四条主线切入，不依赖版本号扫描，直击真实攻击面。
查入口与错误回显是否暴露调试信息
在浏览器访问一个不存在的路由（如 /index.php/abc/xyz），观察响应体：
- 若返回完整 ThinkPHP 错误堆栈、文件绝对路径、数据库配置片段或 PHP 版本细节，说明 APP_DEBUG = true 且未禁用错误显示——这是高危信号，攻击者可直接推断目录结构和敏感路径；
- 检查 public/index.php 是否仍调用
think\App::run()，确认为 TP5/6 架构；若看到require './ThinkPHP/ThinkPHP.php'，则属老旧 TP3.x，需重点排查已知 RCE 链路； - 用 curl 查响应头：
curl -I https://yoursite.com，看 X-Powered-By 是否明文泄露 ThinkPHP/6.0.12 类似版本——匹配 CVE 数据库可快速定位是否含远程命令执行漏洞。
验日志与 runtime 目录是否可被直接访问
ThinkPHP 默认将日志写入 runtime/log/ 或旧版 Application/Runtime/Logs/，若 Web 服务器未限制访问，攻击者可下载日志反推管理员行为甚至数据库密码。
- 手动尝试访问：
/runtime/log/202608/26/10.log（按当前日期构造）或/Application/Runtime/Logs/Home/26_08_26.log； - 若返回 200 且内容为 JSON/数组格式日志，说明日志路径未设访问控制；
- 在 Nginx 配置中应明确禁止：
location ^~ /runtime/ { deny all; }；Apache 则需 .htaccess 禁用或目录权限设为 750 并归属 web 用户组。
审中间件与权限逻辑是否真生效
很多项目只在前端隐藏按钮，后端却无校验，造成垂直/水平越权。审计时不能只看有没有 Auth 中间件，而要看它是否覆盖所有敏感接口并正确取值。
立即学习“PHP免费学习笔记（深入）”；
- 检查中间件中获取用户 ID 的方式：是否优先用
Auth::id()，JWT 场景是否从$request->attr('user')['id']取，有无兜底校验X-User-ID头的真实性； - 搜索控制器方法里是否出现硬编码跳过验证（如
if ($user->is_admin) {...}却没走统一鉴权）； - 用普通用户 Token 尝试请求
/admin/user/delete?id=123，看是否返回 403 还是静默成功——后者说明 RBAC 规则未绑定到路由或中间件漏配。
扫代码中常见危险模式
不用跑全量 SAST 工具，聚焦 ThinkPHP 生态高频漏洞点，用 grep 快速定位：
-
SQL 拼接：搜
Db::query(.*\$_、->where.*\$_GET、->where.*\$_POST，凡未用预处理或参数绑定的，均需重构； -
文件操作风险：搜
include(.*\$_、require_once(.*\$_、file_get_contents(.*\$_，尤其注意拼接路径含用户输入； -
反序列化入口：搜
unserialize(、phar://，TP6 中部分扩展或自定义解包逻辑可能绕过默认防护； -
上传逻辑：搜
move_uploaded_file、Upload::save，确认是否校验 MIME、扩展名、文件头，且保存路径不可执行（chmod -R 755 uploads/）。
不复杂但容易忽略。真正有效的审计不是找“有没有漏洞”，而是验证“防御是否闭环”。
