ModSecurity | open source , cross platform web application firewall | Firewall library

Core Rule Set Developer on Duty here. To confirm: when a user takes a legitimate action (making a download, as you mentioned) then that is the error log entry that appears? And the URL in your error message:

https://jlam.com/rs/pages/download_progress.php?ref=18275

looks legitimate? If so, then your intuition is correct: that is indeed a false positive! Core Rule Set rule 932115 is matching in error.

False positives need to be tuned away to make a given web application fully usable through a WAF. We've written extensively about how to do this in our official documentation, which you can find here: https://coreruleset.org/docs/configuring/false_positives_tuning/

Let's look at the exact issue from your example:

Core Rule Set Dev on Duty here. As the list of exclusions you gave comes from someone else's blog post it's probably best to ignore them. They disable some key functionality of the Core Rule Set (the 9xxxxx rules you're using is the OWASP Core Rule Set) so it's best not to apply those rule exclusions unless you're certain you know what you're doing and why those exclusions are required.

The three entries from the "HitList" that you quoted: are you certain those are the result of known good traffic? Are those definitely from when you were trying to update a page and you got 403 errors? If you're sure those are genuine false positives (and not attacks) then let's continue…

• The rule causing the false positive: 921110
• The location in question: /wp-admin/post.php
• The variable causing the false positive: ARGS:content

Applying a rule exclusion means poking a hole in your WAF's security. We want to try and be as specific as possible so that we make only the smallest hole necessary. We just want to let through the transactions that are being blocked in error and nothing more. We don't want to open a large hole and present an opportunity for attackers to get through.

With that in mind, let's try taking the following approach: let's exclude only the variable in question (ARGS:content) and exclude it only from the rule causing the issue (921110) and only for the location we've seen the problem occur at (/wp-admin/post.php).

Putting all that together looks like so:

Core Rule Set Dev on Duty here. Rule 942100 is one of our 'LibInjection' rules. LibInjection is quite opaque (it's a third party library/operator), so you're correct that a rule exclusion is the way to fix this issue.

The use of regular expressions in this context follows a specific form. They need to be sandwiched inside forward slashes, like so:

Unfortunately the mentioned documentation above doesn't describe the & "operator" in case of SecRule's variables. This character has a special meanings:

• if the variable is a collection (eg. ARGS), then using of & gives back the length of collection. Eg. &ARGS gives you how many arguments are there
• if the variable is a string (eg. REQUEST_URI) then it gives the length of it's value. You can use it for collection members, eg. &REQUEST_HEADERS:Host

You can use this form against the operator @eq with a numeric argument, eg. @eq 0.

So, based on your clarification, I think you can use something like this:

The SecRuleUpdateTargetById rule exclusion you provided looks good to me.

To be clear, the effect of that rule exclusion is:

• Rule 941170 no longer applies to the screen argument
• Rule 941170 still applies to all other arguments as usual
• All other rules still apply to all arguments, including screen, as usual

Is there a reason you're not happy with this?

If you're running a super-high security setup which means that the SecRuleUpdateTargetById rule exclusion is too coarse, two suggestions I would make:

• If appropriate for your web application, limit the rule exclusion for rule 941170 to only apply to the screen argument and only for a given location (for example, only for requests to /login.php)

• Limit the rule exclusion for rule 941170 to only apply to the screen argument and only when screen begins with the string data:image/jpeg;base64

You could even combine both of those suggestions to be extremely specific.

If either, or both, of those sound applicable to your situation, let me know if you would like help to put those rule exclusions together.

Also, what paranoia level are you currently running in, out of interest?

Regarding your suggestion to modify rule 941170's regular expression, it's a bad idea to directly modify third-party rules, such as the Core Rule Set rules. You essentially end up creating your own fork of the rule set, and you're left with the responsibility for maintaining any modifications you make. Upgrading the rule set would become difficult: you would have to remember to keep re-applying, and possibly change, your modifications. In short: rule exclusions are the way to go!

The second rule exclusion described above may look something like this:

Your rule looks mostly correct.

1. Make sure that the SecRuleEngine directive is set to On and not DetectionOnly, otherwise your rule's drop action will never be executed, even if the rule matches.

   Note: Check your error log file. If you see that your rule is matching (and being logged) but your tests aren't having the expected result (no dropped connections), that would suggest that your ModSecurity instance is in DetectionOnly mode.

   You could also swap out drop for deny, which may be easier to test with (a 403 response would be a concrete indication that your rule was working!).

2. If you do need to anchor your regular expression, you could use:

Looking at the part of the regular expression for rule 920100 that deals with the CONNECT method:

Well, seems like I found an answer myself. Will leave it here so it can help someone (maybe me in the future).

Code of the client's send method:

The first line from the server error logs you provided is a ModSecurity log line. We can see that the Comodo WAF is in use: