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