ModSecurity multipart/form-data请求REQUEST_BODY规则不生效问题

ModSecurity 2.x 对不同编码类型的POST请求体处理逻辑有明确差异：

• 当请求Content-Type为application/x-www-form-urlencoded时，ModSecurity完成表单参数解析后，仍会将完整原始请求字符串填充到REQUEST_BODY变量，因此原有规则可正常触发拦截。
• 当请求Content-Type为multipart/form-data时，ModSecurity默认启用专用multipart解析器拆分表单分片，不会将完整原始multipart报文填充到REQUEST_BODY变量，你日志中看到的"Rule returned 0"就是因为匹配目标变量本身不存在"server"字符串——对应内容已经被解析为独立的BODY参数，和你写的匹配目标不对应。

根据实际需求二选一即可：

方案1：直接匹配解析后的表单参数（推荐） #

如果你的需求是检测multipart表单内的字段名、字段值，直接使用ModSecurity预解析生成的参数变量即可，不需要匹配原始请求体，性能开销最低，也是WAF规则编写的通用做法。规则示例：

# 匹配POST请求所有参数（包含参数名、参数值）中含"server"的请求
SecRule ARGS:POST "server" "id:1234,phase:2,t:none,deny"

# 仅需匹配参数值的话用ARGS_POST即可
# SecRule ARGS_POST "server" "id:1234,phase:2,t:none,deny"

方案2：强制让REQUEST_BODY保留multipart原始报文 #

如果你确实需要匹配完整原始multipart请求体（比如检测跨分片的攻击特征），需要在所有业务规则之前加载如下配置，让ModSecurity解析multipart的同时保留原始请求体内容：

# 根据业务场景调整请求体大小阈值，单位为字节，示例值为128KB
SecRequestBodyNoFilesLimit 131072
SecRequestBodyAccess On

配置完成后重启Web服务，原有基于REQUEST_BODY的规则即可在multipart请求场景下正常触发。

注意：multipart请求中上传的文件内容不会被填充到REQUEST_BODY变量，文件内容会单独存储在FILES_*相关变量中，避免大文件占用过多服务内存。

如果需要确认变量实际取值，可以临时开启ModSecurity调试日志，将调试级别设置为4：

SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 4

触发测试请求后查看日志，即可看到REQUEST_BODY变量的实际填充内容，确认匹配逻辑是否符合预期。

内容的提问来源于stack exchange，提问作者quenty658