数据库审计能发现参数化查询漏网的SQL注入行为，因其直接捕获运行时SQL语句，可识别动态拼接表名、UNION查询、高危函数调用及盲注探测等异常操作，覆盖WAF和参数化防护失效场景。
数据库审计能发现参数化查询漏网的SQL注入行为
参数化查询不是万能的。当业务中存在动态表名、列名或ORDER BY子句拼接时，开发者往往被迫绕过预编译，改用字符串拼接——这类代码在静态扫描中容易被忽略，但会在运行时暴露真实SQL结构。数据库审计系统不依赖代码逻辑，而是直接捕获SELECT * FROM users WHERE id = 1 UNION SELECT username,password FROM mysql.user这类异常长查询、含UNION/SELECT ... FROM information_schema的语句，或高频执行的相同模板不同参数的盲注探测请求。
审计日志可定位“合法凭证下的越权操作”
攻击者拿到一个低权限账号后，常通过SQL注入扩大权限边界，比如用SELECT LOAD_FILE('/etc/passwd')读取系统文件，或用SELECT ... INTO OUTFILE写入Webshell。这类操作本身不报错、不触发WAF规则，但会出现在数据库审计日志中。若审计策略配置了对LOAD_FILE、INTO OUTFILE、EXECUTE IMMEDIATE等高危函数的实时告警，就能在数据泄露前拦截。
内网横向移动时，防火墙和WAF完全失效
数据库审计是唯一能覆盖内网直连场景的安全层。当攻击者已突破边界、从运维跳板机或CI/CD服务器直连数据库时：
- WAF无法介入（流量不经过HTTP入口）
- 应用层参数化查询可能被绕过（如通过存储过程调用）
- 数据库账户本身有合法连接权限
SELECT * FROM sys.syslogins（SQL Server）或pg_sleep(5)（PostgreSQL时间盲注）这类非业务行为。错误信息泄露+审计缺失=攻击链闭环
很多系统在开发环境开启详细错误提示，导致MySQL error: You have an error in your SQL syntax near 'xxx'直接返回给前端。攻击者利用该信息快速试错，而审计系统若未开启SQL文本全量记录，就无法还原攻击者构造的每一条试探语句。必须确保审计配置中启用了log_statement = 'all'（PostgreSQL）或general_log = ON（MySQL），否则只记执行结果、不记原始SQL，等于关掉了最关键的眼睛。
真正难防的不是明面上的' OR 1=1 --，而是嵌在ORM底层、藏在批量更新逻辑里、混在日志分析脚本中的SQL拼接——这些地方人眼难查、自动化工具易漏，只有数据库审计能靠真实执行流把它揪出来。
