漏洞修复后日志仍有异常访问，说明攻击行为可能未被完全阻断或修复不彻底，也可能是扫描器持续试探、旧流量残留或存在绕过逻辑；需区分日志来源，thinkphp runtime/log/仅记录框架内异常，非恶意请求本身，真实攻击特征应查nginx access.log，并验证中间件是否生效、修复是否覆盖全链路。
漏洞修复后日志里仍有异常访问，说明攻击行为可能未被完全阻断，或修复不彻底，也可能是旧流量残留、扫描器持续试探、甚至存在绕过逻辑。重点不是“有没有异常”，而是“这些访问是否真构成威胁”以及“日志是否真实反映攻击路径”。
先确认日志来源是不是ThinkPHP自身
ThinkPHP的runtime/log/只记录框架内抛出的异常（如路由未匹配、中间件拦截失败、控制器方法不存在等），而真正的恶意请求（比如SQL注入payload、目录遍历尝试）若未触发PHP错误或框架异常，根本不会进这里。
- 打开
runtime/log/$(date +%Y-%m)/$(date +%d).log，只查含[error]或[warning]且带具体文件/行号的条目——纯URL访问记录（如GET /phpinfo.php）大概率来自Web服务器日志，不是ThinkPHP写的 - 用
tail -f /var/log/nginx/access.log | grep -E "(sqlmap|union select|\.php\?a=|etc/passwd)"实时抓真实攻击特征，比盯着ThinkPHP日志更直接 - 如果日志里全是
Route not found: /xxx，大概率是扫描器在爆破路径，不是漏洞利用成功
检查中间件和全局过滤是否生效
很多“修复”只改了某处代码，但没同步更新请求入口的防护逻辑。ThinkPHP靠中间件做统一校验，若中间件没加载或顺序错，修复就形同虚设。
- 确认
app/middleware.php中是否注册了安全中间件（如防SQL注入、XSS过滤），且位置在AllowCrossDomain之类之后、路由之前 - 在中间件
handle()开头加一行Log::info('security middleware triggered for ' . $request->url());，再复现异常访问，看这条日志是否出现——不出现说明中间件根本没跑 - 检查
config/middleware.php里'http' => [...]数组是否漏掉了你新加的中间件类名
验证漏洞点是否真被堵死，而非仅表面修复
例如修复SQL注入时只对某个参数做了htmlspecialchars()，但同个接口其他参数仍直拼SQL；或修复文件上传漏洞时只限制了后缀，却没校验Content-Type和文件头。
- 用Burp或curl重放日志里的异常请求，观察响应：返回500/404是拦截成功；返回200且有敏感数据（如数据库报错、文件内容）说明修复失效
- 重点复测原漏洞路径：
/index.php?s=admin/index&file=../../../etc/passwd、/index.php?s=index/test&ids[0]=1 and 1=1等典型payload - 检查修复代码是否覆盖所有调用链——比如模型层用了
where()，但控制器里又手动拼了DB::query("SELECT * FROM user WHERE id = {$id}")
排查日志本身是否被污染或误报
有些“异常访问”其实是监控脚本、CDN预热、搜索引擎爬虫或内部健康检查，不是攻击。
- 用
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10查高频IP，再查对应UA字段：如果是python-requests或sqlmap，基本确定是攻击；如果是Baiduspider或Googlebot，属正常爬取 - 对比ThinkPHP日志和Nginx access.log的时间戳：若ThinkPHP无记录，但Nginx里有大量404，说明请求根本没进框架，只是扫路径，不用过度反应
- 检查是否启用了
LOG_RECORD => true但level只设了['error']——这样warning级的可疑行为（如参数类型不符）就被忽略了
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
