See issues causing the plugin to get less than A+ grade
In our testing of WordPress firewall plugins, the NinjaFirewall plugin has been the best free option. It turns out it does something else where it isn’t so good. That would be warning about vulnerable plugins.
We recently noticed the developer mentioning that it warns about vulnerable plugins. They wrote this: [Read more]
We recently looked at yet another example of the limited value that rules written for specific WordPress plugin vulnerabilities offered with the Wordfence Security plugin. But what about the other firewall plugin that has rules being written for it, NinjaFirewall? In looking at the latest rule added to that, we found rules for that can also be of limited value. This highlights the importance of general protection, as opposed to rules written for specific vulnerabilities. Something that both plugins are not focusing on enough, though, NinjaFirewall has done a better job on.
Here is the rule data for NinjaFirewall’s latest rule: [Read more]
In October 2021, we found that the Wordfence Security plugin for WordPress more than double the peak memory usage over WordPress by itself. That compared to a minimal memory increase by the two WordPress firewall plugins that provided more protection than it. Those two plugins also had a significantly smaller performance penalty than Wordfence Security. It obviously is a bad tradeoff to get less protection for more memory usage and a higher performance penalty.
In discussing that memory usage, we quoted a Wordfence employee that had claimed that they are “constantly working on making the plugin” “use less resources”. That certainly sounds impressive, but Wordfence has a long track record of impressive claims that turn out to not be true. It also doesn’t make sense. You can’t constantly do that. You should hit a point where you can’t do anymore. The changelog for the plugin doesn’t have entries that suggest that is true either. [Read more]
Last week, we noted that the marketing for the Wordfence Security plugin was promoting its firewall as being the industry leader, despite that not being supported by them with anything whatsoever and objective testing showing that being far from the case. In doing that, we included a screengrab of them making that claim:
It isn’t uncommon to see people asking the developers of WordPress security plugins if they can be used alongside another security plugin. That often seems like an odd question, as the two plugins being asked about are all-in-one security plugins that both claim to provide all the protection you need. If someone doesn’t trust the developer of either to deliver what they promise, why would they trust that combining two of them would deliver that? The results of testing we do provides evidence that this isn’t the approach to get the best security or even any security.
Across testing we do of security plugins to see if they could provide protection against vulnerabilities in other plugins, many of the plugins provide no protection. Combining multiple plugins that provide no protection, won’t produce a better result. But what if you combine plugins that do provide protection? [Read more]
When it comes to protecting WordPress websites from being hacked through vulnerabilities in plugins, the solution is often simply keeping plugins up to date. But that doesn’t work when a hacker finds a vulnerability and starts exploiting it, otherwise known as a zero-day, as there is no update available. That is where an additional security plugin or service can possibly provide protection. But do they? The answer is often that they won’t. Making that more problematic is that often the marketing of the solutions would tell you otherwise.
Recently, we looked at one example of how firewall plugins could easily detect and stop exploit attempts for a widely exploited vulnerability, but most didn’t. Let’s look at another example of how a firewall plugin can provide protection. This time with a zero-day. We will touch on a couple of examples of why web application firewalls (WAFs) such as a cloud based security service are unable to handle things as well. [Read more]
Last week there were a spate of largely unhelpful new stories run about websites getting hacked through an already fixed vulnerability in a WordPress plugin not available through the WordPress Plugin Directory, tagDiv Composer. There is a lot that could be discussed with that, but one element stands out to us. It looked like exploitation of the vulnerability should be easily stopped by WordPress security plugins with a firewall. We say that based on our own experience developing such a firewall plugin. That runs counter to something said by Dan Goodin, who inexplicable continues to be employed by Ars Technica, despite repeatedly getting things wrong in his stories. He wrote this:
The malicious injection uses obfuscated code to make it hard to detect. It can be found in the database used by WordPress sites, specifically in the “td_live_css_local_storage” option of the wp_options table. [Read more]
