ModSecurity中POST请求被错误记录为GET请求的审计日志问题分析

问题现象

在使用ModSecurity 3.0.13与Nginx 1.27.2的组合时，发现一个关于审计日志记录异常的问题：当服务器收到包含敏感内容的POST请求时，虽然ModSecurity正确地拦截了这些请求，但在审计日志中这些请求却被错误地记录为GET方法。

问题复现条件

1. 配置一个接收POST请求的端点
2. 添加检测请求体中特定关键词（如"confidential"）的自定义规则
3. 当触发规则拦截请求时，审计日志中会显示为GET请求

技术分析

根本原因

经过深入分析，这个问题与Nginx的内部重定向机制有关。当ModSecurity拦截请求并返回403状态码时，Nginx会根据配置的error_page指令进行内部重定向。默认情况下，Nginx在进行这种内部重定向时会将请求方法强制改为GET。

调试发现

从调试日志中可以观察到两个关键现象：

1. 初始阶段ModSecurity正确识别了POST方法
2. 在拦截请求后，事务重新初始化时，REQUEST_METHOD变量被重置为GET

影响范围

这个问题不仅影响自定义规则，同样会影响OWASP CRS核心规则集触发的拦截。任何被ModSecurity拦截的POST请求在审计日志中都会显示为GET方法，这给安全审计和事件分析带来了困扰。

解决方案

推荐解决方案

使用Nginx的命名location来处理错误页面，可以避免请求方法被修改：

error_page 403 @error;
location @error {
    ssi on;
    internal;
    auth_basic off;
    root /etc/nginx/template;
}

方案原理

命名location(@前缀)的特殊之处在于：

1. 它不会修改原始请求的URI和方法
2. 保持了请求的原始上下文
3. 允许ModSecurity正确记录原始请求信息

最佳实践建议

1. 对于所有ModSecurity与Nginx的组合部署，建议统一使用命名location处理错误页面
2. 在审计日志分析时，注意检查是否有此问题的存在
3. 定期验证拦截日志的准确性，特别是请求方法的正确性
4. 考虑在ModSecurity规则中添加标记来区分原始请求和重定向请求

总结

这个问题揭示了Web应用防火墙与Web服务器深度集成时可能出现的一个典型问题。通过理解Nginx内部重定向机制和ModSecurity审计日志生成原理，我们找到了既保持安全功能又确保日志准确性的解决方案。这种深入的技术理解对于构建可靠的安全监控体系至关重要。