Jester-fr wrote: ↑
Thu Nov 07, 2019 9:56 am
... mod_security blocks the access to the ACP with a 403. Is there any solution to this ?
You may already realize this, but "mod_security" is not some kind of static "just need to write your application to be compatible with it" concept. It's more similar to a virus scanner, where every day (or at least periodically) there are updated definitions or "rules for what seems like it might be malicious" being obtained and applied to the web server configuration by your hosting provider, in order to be "up to date with latest threats."
Exceptions -- or writing these rules to be aware of applications which do intentionally perform a particular behavior even when something that isn't
malicious is happening -- is part of what goes into creating these rules, and part of what gets adjusted about the rules when additional false-positive application scenarios are identified. And if someone doesn't have the technical know-how to fix the rule "on the spot" when a false positive occurs, disabling the rule to work around the false positive is the alternative.
e.g. We've seen a rule before where a rule became published which declared "having the http:// prefix anywhere in submitted form data" was considered a possible exploit. Which indeed, as part of an intentionally malicious scenario, can be true. But the rule already contained a number of known exceptions, where the rule acknowledged well-known applications that were doing this for reasons which weren't actually malicious. By selectively skipping the rule when a particular known applications were receiving the post with specific known field names.
And the rule even already had phpBB in that list of exceptions
and known situations --- but the fact that phpBB also contained custom profile fields with names that couldn't be predicted in advance was still an issue, because the current rule definition hadn't yet taken this "ucp.php might also have this in other fields" condition into account when defining "what phpBB is doing isn't malicious."
I'm not saying that's the specific rule you're hitting; it's just an example of a past scenario where "either the rule needs to be updated with an additional known application exception where the action isn't malicious" to account for additional scenarios the rule hadn't covered; or to work around the issue "this specific mod_security rule needs to be disabled" on your site until the rule can be fixed.
Only your web server log can confirm which specific mod_security rule is currently causing the 403 in your specific case right now, and could confirm what exactly that rule is specifically reacting to. "What can be done about it" depends on your hosting service, and whether they've given you the power to disable certain mod_security rules when necessary from your hosting control panel, versus whether they have the technical ability themselves to understand how to fix the rules, versus whether they're willing to report and work on the issue with whomever is the source of their periodically updated mod_security rules.