多CRS规则触发时，如何降低特定路径的总异常分数？

问题背景 #

已部署Nginx+最新版ModSecurity+OWASP CRS保护WordPress站点，偏执级别设为3。站点运行基本正常，但提交表单时触发多条规则，最终因累计异常分数超过阈值（默认5分）被拦截。希望通过调整规则异常分数而非直接绕过规则来解决问题，但之前基于GPT方案修改的规则无效。

触发的规则详情 #

• Rule ID 920230 - Multiple URL Encoding Detected
  匹配数据：ARGS:data参数存在多次URL编码
  拦截原因：检测到参数编码异常，此类异常常被用于双重编码绕过输入验证
  标签：paranoia-level/2
• Rule ID 920272 - Invalid Character in Request
  匹配数据：请求包含可打印ASCII范围外的字符
  拦截原因：请求体存在编码或意外字符
  标签：paranoia-level/3
• Rule ID 942430 & 942431 - SQL Injection-Like Patterns
  匹配数据：表单数据包含过多特殊字符（如&、=、%）
  拦截原因：含过多特殊字符的请求被标记为潜在SQL注入尝试
  标签：paranoia-level/2（942430）、paranoia-level/3（942431）
• Rule ID 949110 - Inbound Anomaly Score Exceeded
  拦截原因：请求累计异常分数超过默认拦截阈值（5分），由上述多规则触发导致

之前尝试的无效规则 #

# Adjusting anomaly scores for specific rules and paths

# Rule adjustments for /wp-admin/admin-ajax.php
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900500,\
    phase:1,\
    pass,\
    t:none,\
    setvar:'tx.notice_anomaly_score=1',\
    setvar:'tx.warning_anomaly_score=2',\
    setvar:'tx.error_anomaly_score=3',\
    setvar:'tx.critical_anomaly_score=4'"

# Specific rule: 920230 (Multiple URL Encoding Detected)
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900501,\
    phase:2,\
    pass,\
    t:none,\
    ctl:ruleModifyById=920230;"

# Adjust anomaly score for rule 920230
SecAction \
    "id:900502,\
    phase:2,\
    pass,\
    t:none,\
    setvar:'tx.anomaly_score=-1',\
    chain"
    SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "t:none"

# Specific rule: 920272 (Invalid character in request body)
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900503,\
    phase:2,\
    pass,\
    t:none,\
    ctl:ruleModifyById=920272;"

# Adjust anomaly score for rule 920272
SecAction \
    "id:900504,\
    phase:2,\
    pass,\
    t:none,\
    setvar:'tx.anomaly_score=-1',\
    chain"
    SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "t:none"

# Specific rule: 942430 (SQL Character Anomaly Detection, 12 characters)
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900505,\
    phase:2,\
    pass,\
    t:none,\
    ctl:ruleModifyById=942430;"

# Adjust anomaly score for rule 942430
SecAction \
    "id:900506,\
    phase:2,\
    pass,\
    t:none,\
    setvar:'tx.anomaly_score=-1',\
    chain"
    SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "t:none"

# Specific rule: 942431 (SQL Character Anomaly Detection, 6 characters)
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900507,\
    phase:2,\
    pass,\
    t:none,\
    ctl:ruleModifyById=942431;"

# Adjust anomaly score for rule 942431
SecAction \
    "id:900508,\
    phase:2,\
    pass,\
    t:none,\
    setvar:'tx.anomaly_score=-1',\
    chain"
    SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" "t:none"

# Evaluate and block based on reduced anomaly score
SecRule TX:BLOCKING_INBOUND_ANOMALY_SCORE "@ge 5" \
    "id:900509,\
    phase:2,\
    deny,\
    log,\
    t:none,\
    msg:'Inbound Anomaly Score Exceeded (Adjusted Score)',\
    tag:'OWASP_CRS',\
    tag:'anomaly-evaluation',\
    setvar:'tx.blocking_inbound_anomaly_score=+5'"

可行解决建议 #

方案1：针对性调整目标路径下规则的异常分数 #

直接修改触发规则在/wp-admin/admin-ajax.php路径下的严重级别，降低其异常分数权重。默认OWASP CRS中，NOTICE级对应1分、WARNING对应2分、ERROR对应4分、CRITICAL对应5分，调整后总分数不会超过阈值：

# 仅对/wp-admin/admin-ajax.php路径调整指定规则的严重级别
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900001,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleUpdateById=920230,severity=NOTICE,\
    ctl:ruleUpdateById=920272,severity=NOTICE,\
    ctl:ruleUpdateById=942430,severity=NOTICE,\
    ctl:ruleUpdateById=942431,severity=NOTICE"

方案2：单独提高目标路径的拦截阈值 #

如果不想修改规则本身的分数，可以给表单提交的目标路径单独设置更高的异常分数阈值：

# 为/wp-admin/admin-ajax.php路径设置更高的拦截阈值（示例设为10分）
SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:900002,\
    phase:1,\
    pass,\
    nolog,\
    setvar:'tx.blocking_inbound_anomaly_score=10'"

方案3：排除特定参数的规则检测 #

针对频繁触发规则的ARGS:data参数，单独排除对应规则的检测（需确认该参数为合法表单提交参数，无安全风险）：

# 排除ARGS:data参数触发920230规则
SecRule ARGS_NAMES "@streq data" \
    "id:900003,\
    phase:2,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=920230"

# 排除ARGS:data参数触发942430、942431规则
SecRule ARGS_NAMES "@streq data" \
    "id:900004,\
    phase:2,\
    pass,\
    nolog,\
    ctl:ruleRemoveById=942430,\
    ctl:ruleRemoveById=942431"

方案4：根源修复表单提交问题 #

从表单本身出发解决触发规则的原因：

• 检查前端代码，确保data参数不存在重复URL编码的情况
• 排查表单输入是否包含非打印ASCII字符，去除或转换此类字符后再提交

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