核心是盯紧请求中“不该出现却频繁出现”的字符、编码和结构模式；重点关注url参数中的单引号、sql/命令/模板关键字及%27等编码，结合grep/awk筛查，并叠加状态码与响应大小交叉验证。
识别恶意数据注入尝试，核心是盯紧请求中那些“不该出现却频繁出现”的字符、编码和结构模式。Nginx 日志虽不直接记录 POST 请求体（除非额外配置），但 URL 参数（$args）和请求行（$request）已足够暴露绝大多数 SQL 注入、命令注入和模板注入的痕迹。
重点看 URL 参数里的高危信号
注入攻击往往把 payload 塞进查询参数里，比如 ?id=1' OR '1'='1 或 ?cmd=cat%20/etc/passwd。需重点关注：
- 单引号（
'）、双引号（"）、分号（;）、括号（()）—— 尤其在参数值中间或末尾单独出现 - SQL 关键字：union、select、insert、drop、delete、exec、sleep、benchmark、load_file、into outfile
- 系统命令关键词：cat、ls、id、whoami、curl、wget、bash、sh、nc、perl、python
- 模板/表达式关键字：
${、#{、__import__、eval(、exec(、system( - URL 编码字符：
%27（'）、%22（"）、%3B（;）、%00（NULL）、%20（空格）—— 多次编码如%2527更要警惕
用命令快速筛出可疑请求
无需导入数据库，一条 shell 命令就能定位线索：
- 查 SQL 注入特征：
grep -iE "(union\s+select|select\s+.*from|insert\s+into|drop\s+table|sleep\(|benchmark\()" /var/log/nginx/access.log - 查命令注入痕迹：
grep -iE "(cat\s+/|ls\s+-|id\s*$|curl\s+http|wget\s+http|bash\s+-|sh\s+-)" /var/log/nginx/access.log | grep -E "\.php\?|\.jsp\?|\.asp\?" - 查编码绕过行为：
awk '$7 ~ /%27|%22|%3B|%00|%2527/ {print $1, $4, $7, $9}' /var/log/nginx/access.log | head -20 - 查异常长参数（常见于 base64 或混淆 payload）：
awk 'length($7) > 500 {print $1, length($7), $7}' /var/log/nginx/access.log | head -10
结合状态码与响应大小交叉验证
单看请求可能误报，叠加响应特征能显著提升准确率：
- 大量
500或503错误 + 含sleep(或benchmark的请求 → 高概率盲注探测 -
200响应但$body_bytes_sent异常大（如超 1MB）→ 可能触发了数据导出或文件读取 - 同一 IP 在短时间内反复触发
404+ 含.env、web.config、/etc/passwd路径 → 文件读取类注入尝试 - 状态码为
302或301，但$http_referer为空或来自非常规域名 → 常见于跳转型 XSS 或 SSRF 注入
让日志本身更“可审计”
默认日志缺少关键上下文。建议在 http 或 server 块中增强记录：
- 添加
$http_user_agent和$http_referer—— 识别 sqlmap、curl、python-requests 等工具指纹 - 启用
$request_length和$body_bytes_sent—— 辅助判断请求体积是否异常 - 对 POST 请求，配合
ngx_http_lua_module在log_by_lua_block中记录ngx.var.request_body（需开启client_body_buffer_size） - 若已部署 ModSecurity，可将
sec_audit_log_parts ABCFHZ日志接入分析流程，获取更完整的 payload 解析
