OWASP ModSecurity 2.9 on IIS Causing 403 Forbidden

Question

I have an ASP.NET Core 3.2 web app hosted on IIS. My site is hosted in a shared environment using Plesk. When I have a look at the Web Application Firewall page it shows the Core Rule Set as "OWASP (free) running on IIS (ModSecurity 2.9)".

Some of my clients have been getting a lot of 403 Forbidden errors when accessing the site. This seems to happen more for users on iOS than Android or Desktop. Users often have to delete their iPhone's Safari web data including cookies, and the 403 is soon back again.

After looking into the ModSecurity audit log file I can see a lot of entries and most of them seem to be false positives. For example, access is often denied by rule #942440 being triggered, which thinks it's an SQL injection attack. This rule detects SQL comment character sequence found within REQUEST_COOKIES. I don't know why the cookie includes these characters. I'm using AspNetCore Authentication and Identity.

I did some research online into ModSecurity and the Core Rule Set, and it seems that CRS 3 has over 90% reduction of false alerts. The Plesk console for my hosting shows version 2.9 and it's especially frustrating because when trying to get support from the hosting provider, I get one line answers that are not particularly helpful. For example, I asked about updating to CRS 3 and the reply was "The updating of the WAF is all managed by Plesk I believe."

I also don't know what the Paranoia Level is set to as it doesn't show this on the Plesk Web Application Firewall page. My only options for mode are off, on, or detection/log only.

After looking more into the contents of the audit log file, I found another rule (#942450) "SQL Hex Encoding Identified" seems to also be causing grief. This rule looks for strings of the pattern '0x' with two additional hexadecimal digits. This is a hexadecimal encoding which can point to an exploit being used, but the problem with this encoding is that session cookies can sometimes contain this pattern.

Ignoring cookies whose name matches a certain pattern is not something ModSecurity allows you to do, so I think the only viable approach is to have this rule ignore all cookies. At least this way the rule is still intact for post and query string parameters, but it won't trigger on cookies anymore. I don't know how this can be done too because I don't know how to limit the exclusion at two parameters (ModSecurity collections), leaving the rest of the rule intact. And on the Plesk page it only gives me the ability to deactivate security rules by specifying their ID's.

Can anyone advise what I can do in this situation? I feel like I should look at changing my hosting provider to one that provides better service/support and affords me greater control over the WAF. My site is not that large (less than 1GB). At some point I also need to consider updating it from Core 3.2 to .NET 6 or 7. My location is Australia.

Answer 1

on-duty program.

Unfortunately the biggest problem is this:

My only options for mode are off, on, or detection/log only.

But let's see the mentioned rules.

For example, access is often denied by rule #942440 being triggered, which thinks it's an SQL injection attack. This rule detects SQL comment character sequence found within REQUEST_COOKIES. I don't know why the cookie includes these characters.

The rule 942440 is activated on PL2, this means your WAF is on PL2 at least. But this rule also checks the REQUEST_COOKIES_NAMES (eg. "PHPSESSID"), ARGS_NAMES (eg. "user") and ARGS (eg. user variable's value).

Rule 942450 also checks the same targets. Without details (eg. full content of audit.log for a transaction) it's very hard to figure out what's wrong.

But consider you can localize the problem. As you wrote the issue happens usually when a client uses iOS, and the client triggers one or more rules above.

You can solve the problem only with an exclusion. But if your possibility is only to turn on/off/detection only, then you won't be able to add any exclusions - as you wrote here:

And on the Plesk page it only gives me the ability to deactivate security rules by specifying their ID's.

Yes, this is a big trouble.

Can anyone advise what I can do in this situation?

If I were you in this situation, I would look for another provider, or if it's too complicated, turn off these rules and check your application twice that it does not allow input which looks like those rules filter.