Hi,
We are seeing false positives when using Auth0 and ModSec for 942440 inside REQUEST-942-APPLICATION-ATTACK-SQLI.conf.
The issue is the callback URL they use contains a query string parameter "state" which can sometimes contain double hyphens, e.g. "Jun1xPDO--e6jut6n9y7ahOdByyzq-A877Z-Ef3Se88". ModSec sees this as a SQLi, and blocks the request.
Auth0 won't change this behaviour so I was curious if we could safely change this rule. I don't want to just turn the rule off, and if I remove "ARG" from the rule, again I feel this is a bit heavy handed. Is there an easy adjustment we can make to get ModSec working with this without opening ourselves to SQLi?
We are using ModSec CRS 3.0.0.
Thanks for the help!
Hi @jammasterj89 this can sometimes occur with general random content. It is quite easy to change this on your instance however because there will always be random stuff we can't make an explicit exception built into the rule (think a bunch of monkeys slamming on keyboards writing Shakespeare).
Now to how to add exceptions. If you want to keep the rule (which I think you should) there are a number of ways to go about this. You can start by removing the particular parameter.
There are some examples in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example but for your situation
SecRuleUpdateTargetById 942440 "!ARGS:state"
As this will update the rule on-boot it needs to be placed AFTER the rules so it knows what it's editing.
When we talk about more complex approaches... we can also do this on a transaction basis because this is per transaction it would be BEFORE the rules (REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example). Something like
SecRule ARGS:state "@rx Jun1xPDO\-\-[a-z|0-9A-Z]{19}\-[a-z|0-9A-Z]{5}\-[a-z|0-9A-Z]{7}" "id:1234,pass,nolog,noauditlog,ctl:ruleRemoveById=942440
This will prohibit processing from rule 942440 for any request that has a parameter state that matches the format you prescribed. Let me know if this helped. I'm closing now but if you have more questions feel free to reopen or join IRC #modsecurity on freenode.
Most helpful comment
Hi @jammasterj89 this can sometimes occur with general random content. It is quite easy to change this on your instance however because there will always be random stuff we can't make an explicit exception built into the rule (think a bunch of monkeys slamming on keyboards writing Shakespeare).
Now to how to add exceptions. If you want to keep the rule (which I think you should) there are a number of ways to go about this. You can start by removing the particular parameter.
There are some examples in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example but for your situation
As this will update the rule on-boot it needs to be placed AFTER the rules so it knows what it's editing.
When we talk about more complex approaches... we can also do this on a transaction basis because this is per transaction it would be BEFORE the rules (REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example). Something like
This will prohibit processing from rule 942440 for any request that has a parameter state that matches the format you prescribed. Let me know if this helped. I'm closing now but if you have more questions feel free to reopen or join IRC #modsecurity on freenode.