First you must create an exclusion to avoid activating rule 941320
when the URI is what you given:
SecRule REQUEST_URI "@streq /private-message/create" \
"id:9001120,\
phase:1,\
pass,\
nolog,\
ctl:ruleRemoveById=941320"
then if you want to control the request for that endpoint, you can create a chained rule:
SecRule REQUEST_URI "@streq /private-message/create" \
"id:9001121,
phase:2,
block,\
capture,\
t:none,t:urlDecodeUni,t:jsDecode,t:lowercase,\
msg:'Possible XSS Attack Detected - HTML Tag Handler',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-xss',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/242/63',\
tag:'PCI/6.5.1',\
tag:'paranoia-level/2',\
ver:'OWASP_CRS/3.3.0',\
severity:'CRITICAL',\
chain"
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx <your-modified-pattern...\W" \
setvar:'tx.xss_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'"
or something similar... You can see that the second part of the last chained rule is same that the original rule. Don't forget to put your own pattern to argument.
You have to place it to your custom exclusion ruleset, eg. REQUEST-903.9010-custom-exclusions.conf
, and include it to your server (*.conf
is enough)