最直接有效的方式是在所有对外暴露的PHP脚本顶部注入日志逻辑，用$_SERVER['REQUEST_URI']、$_SERVER['REQUEST_METHOD']、$_SERVER['REMOTE_ADDR']和session_id()拼基础快照，配合error_log($msg, 3, $file)写入自定义路径，避免并发冲突。
怎么在入口处统一记录接口请求日志
不依赖框架或中间件时，最直接有效的方式是在所有对外暴露的PHP脚本顶部注入日志逻辑。重点不是“记录什么”，而是“确保每条请求都经过记录”——哪怕只是简单的一行。
- 用
$_SERVER['REQUEST_URI']、$_SERVER['REQUEST_METHOD']和$_SERVER['REMOTE_ADDR']拼出基础请求快照 - 加上
session_id()（如果已启动会话）或尝试读取$_COOKIE['PHPSESSID']，辅助判断是否为已登录用户 - 避免用
file_put_contents()直接追加，改用error_log()配合自定义日志路径，减少并发写冲突 - 示例：
error_log(date('c') . " [{$method}] {$uri} from {$ip} | sid:" . session_id() . "\n", 3, '/var/log/php/unauth_access.log');
为什么不能只靠 $_SESSION 判断权限状态
很多未授权调用之所以漏掉，是因为开发者默认“没 session 就不会进业务逻辑”，但实际中存在大量绕过场景：比如 admin/export.php 文件开头没做 session_start() 或没校验 $_SESSION['user_id']，攻击者直接 GET 就能触发导出。
- 检查每个 PHP 文件是否真有鉴权逻辑，而不是只看它“在 admin 目录下”
- 特别注意被 include/require 的功能文件（如
/inc/db_backup.php），它们常被遗漏 - 用
grep -r "session_start\|$_SESSION" *.php扫描全项目，再人工确认每处是否真正校验了权限 - 发现没校验的文件，立刻加
if (!isset($_SESSION['role'])) { http_response_code(403); die(); }
怎么从日志里识别可疑的未授权访问模式
单条日志看不出问题，但聚合后就能暴露规律。未授权调用往往表现为高频、低 Session 关联、固定路径、异常 User-Agent 的组合。
- 用
awk '{print $8,$9,$10}' /var/log/php/unauth_access.log | sort | uniq -c | sort -nr | head -20快速找出高频请求路径 - 筛选无 session 的请求：
grep 'sid:' /var/log/php/unauth_access.log | grep 'sid:$' | head -10 - 关注状态码为 200 却无 session 的导出类接口（如
/export?table=users），这类最危险 - 结合 Apache/Nginx 访问日志比对 IP 行为：同一 IP 在 access.log 里有 404，在 unauth_access.log 里却有 200，大概率是目录爆破后命中了未鉴权脚本
如何让日志本身成为防御的一部分
日志不只是事后分析工具，它还能实时阻断和告警。关键是把日志生成和访问控制耦合起来，而不是分离成“先执行再记录”。
立即学习“PHP免费学习笔记（深入）”；
- 在日志写入前加轻量级校验：比如对
/api/v1/delete这类敏感路径，强制要求$_SESSION['role'] === 'admin'，否则不记录日志直接返回 403 - 用
flock()锁定日志文件写入，防止高并发下日志错乱掩盖真实调用序列 - 给关键路径加标记字段，例如在日志里写
[UNAUTH]前缀，方便后续用grep '\[UNAUTH\]'快速提取 - 真正的难点不在记录，而在区分“合法游客访问首页”和“非法扫描后台接口”——这需要结合 Referer、User-Agent、请求频率做简单规则过滤，而不是全量记录后靠人翻
