Hi again,
as always when I raise a question, it manage to butcher the test case. Due to a confusion about which CRS version was being used, the below is only partially true. My findings so far indicate that the initial SecRule fails to trigger, so the ctl: part (no matter if I use ruleRemoveById, ruleRemoveByTag or ruleRemoveTargetByTag) never takes effect.
I've tried variants of
SecRule REQUEST_HEADERS:Content-Type "@unconditionalMatch"
SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)"
SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*"
to make it stick, to no avail. I'm not terribly experienced here and might be beating about the bush in all the wrong ways, but any help would be welcome. Sorry about the noise.
/Eirik
> On 24 Feb 2019, at 16:19, [email protected] wrote:
>
> Hi all,
>
> I feel like I'm going blind here, I'm sure the problem is obvious and (to me) embarrassing. But - I'm trying to write a whitelist rule that selectively disabled a specific rule:
>
> # acs: Some clients stick charsets in content-type request headers
> SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*([^;\s]+)" \
> "phase:request,id:1103,t:none,pass,nolog,tag:'md-debug',chain,\
> ctl:ruleRemoveById=920480"
> SecRule REQUEST_URI "@rx ^(/mdpayacs/pareq|/pan-tokenisation/PanTokenServiceImpl).*" "t:none"
>
> I know the matcher works, because when I use
> ctl:ruleRemoveTargetByTag='OWASP_CRS/PROTOCOL_VIOLATION/CONTENT_TYPE_CHARSET';REQUEST_HEADERS:Content-Type"
>
> the whitelist works as expected. I just think disabling the explicit rule would be the more correct/cheap thing to do.
>
> What am I doing wrong?
> libmodsecurity 3.0.3 and nginx on FreeBSD, CRS 3.1.0.
> Note that it works with CRS 3.0.0 but I think rule 920480 is new in 3.1, so that would explain that part.
>
> /Eirik
>
> _______________________________________________
> mod-security-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
_______________________________________________
mod-security-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.