如何实现SQL防注入审计_开启细粒度SQL查询日志-SQL-PHP中文网

sql防注入不能依赖日志代替防护，日志仅用于事后审计；必须使用参数化查询、orm安全接口或waf规则实现真正防护，日志因不记录实际参数值且存在绕过风险，无法替代输入校验与安全编码。

如何实现sql防注入审计_开启细粒度sql查询日志

SQL防注入审计不能靠日志代替防护

开启SQL查询日志（尤其是细粒度日志）对发现疑似注入行为有辅助价值，但它本身不提供任何防护能力。日志只是事后证据，无法拦截恶意请求。真正防注入必须依赖参数化查询、ORM安全接口或WAF规则，日志只用于回溯和审计。

常见错误现象：SELECT * FROM users WHERE id = '1 OR 1=1' 这类拼接SQL在日志里看起来“正常”，但已构成注入；而参数化查询生成的日志可能是 SELECT * FROM users WHERE id = ?，问号不展开——这意味着你得配合应用层日志或调试信息才能还原实际参数值。

MySQL 默认不记录参数值，general_log 只记原始语句文本，拼接后的恶意SQL会原样出现，但参数化语句则显示占位符
PostgreSQL 的 log_statement = 'all' 同样不展开绑定变量，需搭配 log_min_duration_statement = 0 + 应用层打点才能关联上下文
Oracle 需启用 AUDIT SQL 并配置 audit_trail = db,extended，否则 SQL_TEXT 字段不包含绑定值

MySQL 开启细粒度查询日志的实操要点

MySQL 5.7+ 支持运行时开关，但要注意性能开销和磁盘占用。不要直接开 general_log = ON 到生产库，尤其高并发场景。

临时开启（推荐测试用）：SET GLOBAL general_log = ON;，日志默认写入 hostname.log，路径由 general_log_file 控制
若要记录到表（便于查询）：SET GLOBAL log_output = 'TABLE';，日志存入 mysql.general_log，但该表是 CSV 引擎，不支持索引，查起来很慢
想过滤出高危模式？用 grep -E "(union.*select|;.*--|/\*.*\*/|sleep\()" 扫描日志文件，但注意：编码混淆、大小写绕过、注释变形会让正则漏报
MySQL 8.0+ 可用 performance_schema.events_statements_history_long 查最近执行语句，但默认关闭采集，需提前设 performance_schema_events_statements_history_long_size

PostgreSQL 审计日志中识别注入痕迹的关键配置

PostgreSQL 日志本身不区分“是否参数化”，所有语句都按最终执行形式记录。能否识别注入，取决于应用如何构造SQL以及是否开启足够详细的日志级别。

必须设 log_statement = 'all'，否则只记 DDL 和错误语句
加上 log_parameter_max_length = -1（9.6+），否则参数值被截断，$1 后面的值看不到
log_line_prefix 建议包含 %u %d %h %i（用户、数据库、客户端IP、会话ID），便于关联同一请求的多条语句
典型注入痕迹：SELECT * FROM products WHERE id = '1'::int OR 1=1（类型强制绕过）、UNION SELECT version(), current_user —— 这些在日志里是明文，但前提是没被应用层预处理掉

审计日志不能替代应用层输入校验

很多团队把日志当“兜底”，结果发现大量 WHERE name LIKE '%?%' 类模糊查询出现在日志里，误以为是注入，其实是合法业务逻辑。真正的风险点往往藏在非标准入口：JSON API 的 filter 字段、GraphQL 的变量、甚至 URL 路径参数拼进SQL的地方。

日志里看到 INSERT INTO logs (msg) VALUES ('user login') 很安全，但若实际执行的是 INSERT INTO logs (msg) VALUES ('user login' || (SELECT password FROM admins LIMIT 1))，说明后端用了动态拼接+未过滤子查询
Node.js 的 pg 模块若用 client.query('SELECT * FROM t WHERE id = $1', [input]) 是安全的，但若写成 client.query(`SELECT * FROM t WHERE id = ${input}`)，日志里照样只显示拼接后的字符串，不会标红警告
Java MyBatis 若用 ${xxx} 而非 #{xxx}，日志里也看不出区别，只能靠代码扫描或字节码插桩检测

最常被忽略的一点：日志本身可能被注入污染。比如攻击者提交 username=foo%0A%0D/* SQL comment */ DROP TABLE users;，如果日志系统把原始请求头/体原样落盘，且后续用 Web 界面展示日志，就可能触发 XSS，进而窃取审计员 session。