能定位，但前提是日志开了、格式对、筛选逻辑不漏关键特征——否则查 mysql.general_log 或 fn_dblog 就是看天书。
能定位，但前提是日志开了、格式对、筛选逻辑不漏关键特征——否则查 mysql.general_log 或 fn_dblog 就是看天书。
MySQL general_log 查不到新语句？先确认 log_output 和连接状态
执行了 SET GLOBAL general_log = ON 却没记录，大概率卡在这两个地方：
-
log_output还是'NONE'：必须显式设为'TABLE'或'FILE'，只开general_log不生效 - 已有连接不受影响：日志开关只对新建连接生效，老连接的请求不会进日志，得用新会话复现请求才能捕获
-
mysql.general_log默认用 CSV 引擎，无索引：SELECT * FROM mysql.general_log WHERE argument LIKE '%union%'会全表扫描，日志大了直接卡死
实操建议：先查状态 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 看不到真实参数？缺了 pgaudit.log_parameter
开了 pgaudit 却只看到 WHERE id = ?，payload 全被问号遮住——这是默认配置导致的脱敏行为。
-
pgaudit.log_parameter = off（默认值）：所有绑定参数都以占位符形式记录，攻击 payload 如WHERE id = 1 OR 1=1完全不可见 -
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 才生效。
Nginx access_log 怎么抓到 POST 里的注入 payload？不能只靠 $args
默认 access_log 只记 URL 和 $args，对 JSON 或 form-data 的 POST body 完全不可见。想看到 {"id": "1' UNION SELECT ..."} 这类内容，必须主动增强。
- 直接读
ngx.var.request_body需要ngx_http_lua_module，且依赖client_body_buffer_size和client_max_body_size配置足够大 - 仅靠
$request或$args无法覆盖 Cookie、Referer、User-Agent 注入，这些位置同样高危 - URL 编码字符如
%27（'）、%3B（;）、%00（NULL）需单独匹配，简单 grepunion会漏掉多次编码绕过的 payload
实操建议：在 log_by_lua_block 中记录 ngx.var.request_body，同时在日志格式里加 $http_cookie、$http_referer、$http_user_agent；筛查命令别只盯 union select，补上 grep -E "(%27|%22|%3B|%00)" 和 awk '$9 ~ /^4/ || $9 ~ /^5/' 筛错误响应。
MSSQL 事务日志里怎么识别堆叠注入？重点看分号 + 多语句结构
MSSQL 的堆叠注入（stacked query）不像 MySQL 那样靠 UNION SELECT 显性暴露，它靠分号分隔多条语句，日志里更隐蔽。
- 核心特征是
;后紧跟SELECT、INSERT、UPDATE、DELETE、DROP、EXEC、DECLARE等关键词，比如; EXEC xp_cmdshell 'whoami' - 单看
fn_dblog输出全是 LSN、Operation、Context 字段，得过滤LOP_INSERT_ROWS、LOP_MODIFY_ROW并关联事务 ID 才能还原完整语句链 - 错误日志（
ERRORLOG）里如果出现报错注入的痕迹，如Msg 515, Level 16或Invalid column name，往往说明攻击者正在试探字段数或表结构
实操建议：用 EXEC xp_readerrorlog 快速扫错误日志；查事务日志时优先筛 SELECT * FROM fn_dblog(NULL, NULL) WHERE [Operation] IN ('LOP_INSERT_ROWS', 'LOP_MODIFY_ROW') AND [Context] = 'LCX_USER_TRANSACTION'；再人工检查对应事务的完整操作序列，尤其注意分号后是否混入非业务语句。
真正难的不是找到那条带 union select 的日志，而是从几百 GB 的原始日志里，在没开 log_parameter、没配 log_by_lua_block、没设 log_output 的前提下，靠有限字段反推攻击意图——这时候，时间范围、IP 聚类、状态码分布，比正则本身更重要。
