When it comes to security solutions for WordPress websites, the results of testing we do to see if security plugins provide protection against real vulnerabilities in WordPress plugins are a strong indication that people are not using security solutions based on how much protection they offer, considering how few provide protection. In our latest test, only a quarter of the plugins tested provided protection against a widely exploited vulnerability. Almost all the most popular plugins tested didn’t provide protection. If people are not considering the protection plugins offer, they almost certainly are not considering the unnecessary problems they can cause. What we have seen over the years is that is a missed opportunity, as the problems they cause are often a good way to assess whether they are a good option.

Yesterday, we touched on an example of that where the response from the developer of the Wordfence security plugin to incorrectly blocking contact form submissions was to suggest disabling a core protection that their firewall offers. So there is a problem with their firewall’s protection, but they don’t have any interest in getting it fixed. It’s not a great look.

This week we were contacted by someone asking how web application firewalls (WAFs) compare to firewall plugins and if you need both. We plan to address that in an upcoming post, but part of their question ties in with something we looked at this week. They were specifically asking if a firewall plugin provided the same protection as a ModSecurity based WAF from their web host. The big problem when trying to respond to that question is that what protection and what problems a ModSecurity WAF introduces can vary widely as it depends on what rules are used with it.

As an example of the problems, our monitoring of the WordPress Support Forum this week flagged several topics mentioning a vulnerability in a plugin in the context of what seems to be a faulty ModSecurity rule used by the web host SiteGround. Here is how the problem with it was described:

If both plugins [AIOSEO and SiteOrigin Page Builder] are activated, any attempt to publish a draft or update an existing page gets a 400 error.

This behavior only occurs if there is a value added to the SiteOrigin plugin “Row Style”. If the fields are left blank, the page updates without the 400 error.

This is a new issue and ONLY occurs with our SiteGround hosted websites since they just implemented a new security rule that triggers the 400 error.

Already published pages with the SiteOrigin plugin “Row Style” values already added display normally.

The cited vulnerability that it supposed to be the reason for the problematic rule raises a lot of questions about what is going on:

This rule was indeed implemented due to a quite recent vulnerability of plugin – All In One SEO Pack.

https://www.wordfence.com/blog/2023/02/all-in-one-seo-pack-vulnerabilities-impacting-3-million-sites-patched/

Among the issues there is, is that the vulnerability is one that isn’t of much concern since it only would be exploitable by users that can create WordPress posts. So untrusted individuals likely wouldn’t have the access needed to exploit it. The vulnerability has been fixed, so the rule is at best overlapping the protection provided by simply updating the plugin. Then there is the issue that there shouldn’t need to be a rule written for the specific vulnerability since general protection should already protect against it, since it involves basic cross-site scripting (XSS). That would seem to indicate that their ModSecurity WAF isn’t providing good protection. Though we should note that most WordPress security plugins don’t provide that protection, as in a recent test we did involving the same vulnerability in another plugin, only 4 of them protected against it.

What raises even more questions is part of SiteGround’s response to the problem being caused by it:

We are not familiar with the All In One SEO Pack plugin and its updates but our mod security rule is triggered by the site. We can enable the rule back so you can test the site if you wish, however, the rule cannot be adjusted on our end. Our security team periodically reviews the rules and adjusts them when needed.

So SiteGround apparently implemented a rule without being familiar with what was going on. It’s hard to express how odd it is to hear that they would implement something without having any idea what is going on. The final sentence of that makes the whole thing odder. How would their security team review the rules and adjust them if they don’t have any idea of what they are there for?

Our own firewall plugin provided protection against the vulnerability without needing a rule for it, meaning it provided protection even before the vulnerability was known about. We tested that out with the scenario where SiteGround’s ModSecurity rule caused a problem and there was no issue. So SiteGround’s ModSecurity WAF provided less protection in that situation while also causing a problem, which is quite a bad tradeoff.