对 PHP 应用中数据库敏感操作进行审计，核心是在不侵入业务逻辑的前提下，精准捕获、标记并记录高风险行为，如 delete、DROP、TRUNCATE、UPDATE（无 WHERE）、INSERT INTO … select（含子查询）、权限变更（GRANT/REVOKE）等。关键不是记录所有 SQL，而是识别“可能造成数据丢失、泄露或越权”的操作，并保留上下文用于追溯。
1. 拦截层：统一 SQL 执行入口
避免在每个 pdo::exec() 或 mysqli_query() 处零散埋点。应将数据库操作收敛到一个封装类（如 DbManager），所有业务调用均经由此类。在此类的执行方法（如 query()、execute()）中注入审计逻辑：
- 解析原始 SQL 字符串（使用轻量解析器如 sql-parser 或正则粗筛），提取操作类型（SELECT/INSERT/UPDATE/DELETE/DROP 等）和目标表名
- 判断是否为敏感操作：DELETE 无 WHERE、UPDATE 无 WHERE、DROP table、TRUNCATE、GRANT、REVOKE、包含 union SELECT 或 INTO OUTFILE 的语句
- 若命中，记录完整 SQL、执行时间、PHP 脚本路径、行号、当前用户（$_SESSION[‘user_id’] 或 JWT subject）、客户端 IP、http Referer（如有）
2. 上下文增强：关联请求与身份
单纯记录 SQL 不足以定责。需将数据库操作绑定到具体 HTTP 请求生命周期：
- 在请求入口（如 index.php 或中间件）生成唯一 trace_id，存入全局变量或 Request 对象
- 审计日志中写入该 trace_id，便于与 nginx 日志、APM 调用链对齐
- 从 $_SESSION、JWT、或 API Token 中提取真实操作人标识（非数据库连接用户），例如 DB 连接用 ‘app_rw’，但操作人是 ‘admin@company.com’
- 对 CLI 脚本单独处理：读取 $argv 和 get_current_user()，标记为 “CLI: migrate_v2.3”
3. 存储与分级：日志不进主库，敏感操作实时告警
审计日志必须与业务库物理隔离，防止日志写入拖慢或被误删：
立即学习“PHP免费学习笔记（深入）”；
- 使用独立 MySQL 实例或只读从库存储 audit_log 表，表结构含 id、trace_id、op_type、table_name、sql_hash（SHA256 去除空格和参数）、bind_params（json）、user_id、ip、uri、created_at
- 对高危操作（DROP、TRUNCATE、DELETE * FROM）启用同步告警：写入日志后立即触发企业微信/钉钉机器人通知 dba 和安全负责人
- 普通敏感操作（UPDATE 无 WHERE）可异步写入，降低延迟；非敏感操作（带 WHERE 的 UPDATE）可采样记录（如 1%）或仅记录元数据（表名+操作类型）
4. 防绕过：覆盖预处理与 ORM 场景
攻击者可能绕过简单 SQL 字符串检测。需适配主流使用方式：
- PDO prepare/execute：在 execute() 调用时，获取 bound parameters 并拼回可读 SQL（或至少提取 $stmt->queryString + params），再做敏感判断
- Eloquent/Laravel：监听 IlluminateDatabaseEventsQueryExecuted 事件，在事件处理器中检查 $event->sql 和 $event->bindings
- ThinkPHP：钩子 attach(‘sql_explain’) 或重写 Query 类的 debug 方法
- 禁止直接拼接 $_GET/$_POST 到 SQL——审计系统可附加检测：若 SQL 中出现 ‘$_GET’、’$_POST’ 字样，强制标记为可疑并告警