SQL Server审计日志识别堆叠注入需匹配“分号+多条语句”结构特征，如;\s*(SELECT|INSERT|UPDATE|DELETE|DROP|EXEC|DECLARE)，并过滤BATCH_STARTED/EXECUTE事件，结合低权限账号执行高危操作行为综合研判。
线上环境开启通用日志（general_log）或数据库审计模块后，**绝大多数注入行为会在日志中留下可识别的语法特征**，但直接查表或 grep 很容易漏掉关键线索——核心问题不是“有没有日志”，而是“怎么筛才不被噪音淹没”。
MySQL 的 general_log 表为什么查不到新语句？
常见错误现象是执行了 SET GLOBAL general_log = ON 却在 mysql.general_log 里看不到任何新记录。原因通常有三个：
-
log_output仍是'NONE'，必须显式设为'TABLE'或'FILE' - 已有连接不受影响，需用新连接复现请求才能进日志
-
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 日志里看不到参数值？
开了 pg_audit 却只看到 WHERE id = ? 这种占位符，实际攻击 payload（如 WHERE id = 1 OR 1=1）完全不可见——这是默认配置导致的。
关键参数缺失：pgaudit.log_parameter = off（默认值），必须手动打开；否则所有绑定参数都以问号形式脱敏。
另一个易踩坑点：pgaudit.log_catalog = on（默认值），会导致大量 SELECT * FROM pg_class 类系统表访问刷屏，真正业务语句反而被淹没。实操建议：在 postgresql.conf 中明确设置：pgaudit.log = 'read, write, ddl'、pgaudit.log_parameter = on、pgaudit.log_catalog = off，重启生效。
Nginx 日志中如何精准捕获 POST 请求里的注入 payload？
默认 access_log 只记录 URL 和 $args，对 POST 请求体（如 JSON 或 form-data）完全不可见。想看到 {"id": "1' UNION SELECT ..."} 这类内容，必须主动增强日志。
可行路径只有两条：
- 用
ngx_http_lua_module：在log_by_lua_block中读取ngx.var.request_body，但前提是client_body_buffer_size足够大且client_max_body_size未截断；否则日志里是空字符串或 “-” - 用 ModSecurity + SecAuditLogParts ABIFHZ：把完整请求体写入独立审计日志文件，再用
grep -E "(%27|'|union|sleep()" audit.log扫描
注意：Lua 方式对高并发场景有性能损耗，ModSecurity 需额外部署；二者都绕不开一个事实——**原始 Nginx 日志本身不包含 POST body，不改配置就永远看不到**。
SQL Server 审计日志里怎么识别堆叠注入？
堆叠注入（如 id=1; DROP TABLE users;）在 SQL Server 中不会被自动拆成多条语句记录，整条原始输入会塞进 statement 字段。靠关键词 union 或 select 搜索会漏掉大量变体，比如用 exec(@sql) 动态拼接、或用注释符分隔的多行注入。
真正有效的筛选逻辑是匹配“分号 + 多个独立语句”的结构特征：
- 正则示例：
;s*(SELECT|INSERT|UPDATE|DELETE|DROP|EXEC|DECLARE) - 结合事件类型过滤：
action_id IN ('BATCH_STARTED', 'EXECUTE')，排除纯登录或元数据查询 - 重点看
server_principal_name是否为低权限应用账号，却执行了高危操作
容易忽略的一点：SQL Server 默认不记录语句中的具体参数值，statement 字段里可能是 sp_executesql N''SELECT * FROM users WHERE id = @p1'', N''@p1 int'', @p1=1——此时需配合 query_hash 关联执行计划，或启用 QUERY_STORE 捕获实际运行时的文本。
