必须启用secrequestbodyaccess并确保modsecurity模块正确加载，否则sqli规则完全无效；需验证nginx/apache模块编译、开启请求体解析、配置透传及异常分值拦截。
必须确认 ModSecurity 已正确编译进 Web 服务器，否则所有 SQLi 规则配置都无效。
确认 Nginx 或 Apache 是否真正支持 ModSecurity
ModSecurity 不是“开箱即用”的插件，尤其在 Nginx 中——它必须作为动态模块编译进去。直接写 SecRule 或 SecRequestBodyAccess 会报错：nginx: [emerg] unknown directive "SecRule"。
- 运行
nginx -V 2>&1 | grep -o modsecurity，输出非空才表示模块已加载（如含--add-dynamic-module=../nginx-modsecurity） - 验证动态链接：执行
ldd $(which nginx) | grep modsecurity，无输出说明模块未真正加载 - Apache 用户需检查
mod_security2.c是否启用：a2enmod security2后重启，并确认/etc/apache2/mods-enabled/security2.load存在
启用 SQL 注入检测的必要配置项
OWASP CRS 的 SQLi 规则（如 REQUEST-942-APPLICATION-ATTACK-SQLI.conf）默认不检查 POST body，因为 SecRequestBodyAccess 默认为 Off。漏掉这行，等于关掉了大部分 SQLi 检测能力。
- 全局启用请求体解析：
SecRequestBodyAccess On - Nginx + PHP-FPM 场景下，还需在
location块中显式开启透传：proxy_pass_request_body on;和fastcgi_pass_request_body on;，否则ARGS变量为空 - 对
multipart/form-data请求，CRS 的ARGS_NAMES可能漏匹配，建议加兜底规则：SecRule REQUEST_BODY "@rx (?i)(union\s+select|select\s+.*\s+from)" "id:1002,phase:2,deny,status:403,msg:'Raw SQLi in body'"
绕过检测的常见手法与对应加固点
攻击者用 sel%65ct、UNI/**/ON SEL/**/ECT 等方式绕过正则匹配，而 Nginx 的请求链路中容易丢失二次解码环节，导致 t:urlDecodeUni 失效。
- 规则中必须显式声明转换链，例如：
SecRule ARGS "@rx (?i)union\s+select" "t:urlDecodeUni,t:lowercase,id:1003,phase:2,deny" - 避免依赖单条规则拦截；CRS 使用累加式异常分值（
TX:ANOMALY_SCORE），务必确认最终拦截规则已启用：SecRule TX:ANOMALY_SCORE "@gt 5" "id:999999,phase:2,deny,status:403,msg:'Anomaly score exceeded'" - 若业务使用富文本编辑器或 JSON API，
ARGS匹配易误报，应精准排除：SecRuleUpdateTargetById 942100 !ARGS:content
最常被忽略的是：即使规则文件存在、SecRuleEngine On 已设，只要 SecRequestBodyAccess Off 或后端透传未开启，SQLi 规则就完全不生效——流量根本没被送进规则引擎分析。
