日志是ThinkPHP漏洞排查的第一手攻击痕迹证据源，直接记录SQL执行、未过滤输入、会话ID、异常堆栈及明文密码；需立即检查日志目录是否可外部访问，并重点筛查SQL语句、session/cookie信息和错误堆栈中的高危线索。
排查ThinkPHP漏洞时，日志不是辅助材料，而是第一手攻击痕迹证据源——它直接记录了SQL执行全过程、未过滤的用户输入、会话ID生成逻辑、异常堆栈路径，甚至明文密码临时写入。不看日志，等于闭眼查漏洞。
先确认日志是否可被外部访问
打开浏览器，直接访问 【/Application/Runtime/Logs/Home/】（ThinkPHP 3.x）或 【/runtime/log/】（ThinkPHP 5/6），观察是否返回目录列表或403/404。若返回200且列出.log文件，说明日志目录未做访问限制，漏洞已处于“裸奔”状态。
用curl测试：curl -I http://your-domain.com/Application/Runtime/Logs/Home/24_08_05.log。如果响应头含Content-Type: text/plain且状态码为200，立刻停止所有其他操作，先封目录。
重点筛查三类日志条目
用文本编辑器或grep逐行扫描最近7天的日志文件（如24_08_05.log、24_08_04.log），聚焦以下三类高危内容：
立即学习“PHP免费学习笔记（深入）”；
① 包含 【SQL】 关键字的行：查找类似“SELECT * FROM user WHERE username = 'admin'”或“INSERT INTO log VALUES ('xxx', '123.123.123.123')”的语句。若SQL中参数是未经转义的原始GET/POST值（如WHERE id = $_GET['id']），说明存在拼接式注入风险。
② 出现 【session_id】 或 【cookie】 字样的行：检查是否记录了完整Set-Cookie头，尤其关注是否包含 【httponly=false】 或 【secure=false】。这类日志暴露意味着会话劫持风险极高，攻击者可直接复用cookie登录后台。
③ 含 【PHP Warning】 或 【Fatal error】 的堆栈：定位file路径是否指向控制器或模型层（如/app/controller/Admin.php:128），再看trace里是否有用户可控参数（如$_REQUEST['callback']）参与了函数调用。这是RCE漏洞的典型前兆。
快速定位调试模式残留痕迹
方法一：搜索日志中是否高频出现 【[ DEBUG ]】 标签。ThinkPHP在APP_DEBUG=true时，每条日志开头都会打上该标记。只要发现一处，即证明生产环境仍开启调试模式。
方法二：查找 【_method=】 或 【filter[]=】 相关请求记录。这些参数在日志中反复出现，且后端未拦截，大概率对应ThinkPHP 5.0.23 RCE漏洞利用链。
方法三：翻到日志末尾几行，看最后一条记录的时间戳是否与当前服务器时间接近。若相差超过2小时，说明日志服务可能被禁用或重定向——这本身是异常信号，需倒查config/app.php中log配置项是否被注释或改写。
识别敏感信息硬编码泄露
执行命令：grep -n -i "password\|pwd\|key\|secret\|access_token" *.log。一旦命中，立即人工核对上下文。
特别注意日志中以数组形式打印的变量，例如：[‘config’ => [‘database’ => [‘username’ => ‘root’, ‘password’ => ‘123456’]]]——这种结构往往来自开发者调用dump()或Log::record()时未脱敏，直接把配置数组全量写入日志。
若发现手机号、身份证号明文出现在日志中，说明业务代码在记录用户操作时未做字段掩码处理，违反《个人信息保护法》基本要求。
