怎样通过数据库审计日志准确定位SQL注入漏洞来源-SQL-PHP中文网

mysql general_log 无新语句因log_output为'none'或旧连接未生效；postgresql pg_audit参数显示?因pgaudit.log_parameter=off；sql server堆叠注入需匹配分号+多语句结构及上下文可疑组合。

怎样通过数据库审计日志准确定位sql注入漏洞来源

MySQL general_log 里查不到新语句？先确认 log_output 和连接状态

执行了 SET GLOBAL general_log = ON 却在 mysql.general_log 里看不到任何新记录，大概率卡在这两个地方：

log_output 还是 'NONE'：必须显式设为 'TABLE' 或 'FILE'，只开 general_log 不生效
已有连接不受影响：日志开关只对新建连接生效，老连接的请求不会进日志，得用新会话复现请求才能捕获

实操建议：先查状态 SELECT @@global.general_log, @@global.log_output;；再设 SET GLOBAL log_output = 'TABLE'; SET GLOBAL general_log = ON;；查时加时间范围和 LIMIT：SELECT * FROM mysql.general_log WHERE event_time > NOW() - INTERVAL 5 MINUTE AND argument REGEXP "[[:space:]]*union[[:space:]]+select|sleep\(|benchmark\(" LIMIT 100;

PostgreSQL pg_audit 日志里参数全是 ?，怎么看到真实 payload

开了 pg_audit 却只看到 WHERE id = ? 这种占位符，实际攻击 payload（如 WHERE id = 1 OR 1=1）完全不可见——这是默认配置导致的脱敏行为。

pgaudit.log_parameter = off（默认值）：所有绑定参数都以占位符形式记录，攻击 payload 不可见
pgaudit.log_catalog = on（默认值）：大量 SELECT * FROM pg_class 类系统表访问刷屏，业务 SQL 被淹没

实操建议：在 postgresql.conf 中明确设置：pgaudit.log = 'read, write, ddl'、pgaudit.log_parameter = on、pgaudit.log_catalog = off，改完必须重启 PostgreSQL 才生效。

DrugBank 数据库

访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-

下载

SQL Server 审计日志里识别堆叠注入，关键看分号+多语句结构

堆叠注入（stacked query）不像联合查询那样有明显回显，但会在审计日志中留下「分号 + 多条语句」的结构特征，比如 ; 后紧跟 SELECT、INSERT、DROP、EXEC 等关键词。

必须过滤 BATCH_STARTED / EXECUTE 类事件，避免把存储过程调用误判为攻击
低权限账号执行高危操作（如 EXEC xp_cmdshell）比高权限账号更可疑
单条日志中出现多个 ; 分隔的语句，且第二条开始含非常规关键字（如 WAITFOR DELAY、sp_addsrvrolemember），置信度极高

实操建议：用 T-SQL 查询 sys.fn_get_audit_file，匹配 statement LIKE '%;[^;]*SELECT%' 或 statement LIKE '%;[^;]*(DROP|EXEC|DECLARE)%'，并关联 server_principal_name 和 database_name 做上下文过滤。