When it comes to security products and services one of the many problems is that the public often is making claims about them that are not true. Oftentimes people will claim that a product or service has successfully protected a website when they don’t know that is true. Instead they are assuming that is true because the website was not hacked while using it (that they know of), but considering that most websites don’t get hacked, that correlation does not indicate causation. We have also often seen people repeating claims that products can provide some particular type of protection which seem to be based entirely on an unsupported claim made by the makers of the product or service. Considering the many times we have seen security companies lying (in addition to many falsehoods that we can’t say whether they know what they are saying is true or not) those claims being repeated are often not true.

While looking into a report of a claimed vulnerability in a WordPress plugin the other day we ran into another example of that sort of thing. Someone going by the handle B0UG had claimed that the plugin UK Cookie Consent had contained a persistent cross-site scripting (XSS) vulnerability. A new version of the plugin was released, which indicated that this had been a vulnerability:

• Fixed: fixed security vulnerability identified by James Boughey

As we discussed in more detail in our weekly post on claims of vulnerabilities in WordPress plugins that are not really vulnerabilities, there really wasn’t a vulnerability here since the supposed vulnerability involved a situation where WordPress users are specifically permitted to use the equivalent of XSS.

In the remediation of section of the report there is the following information:

Update to the latest version available. Implement a web application such as Wordfence.

Considering that this wasn’t really a vulnerability we wondering if the plugin Wordfence Security would truly stop this as claimed. It seemed unlikely, since, as we just mentioned the supposed vulnerability involved action that is actually permitted to be happening.

To test things out, we created a fresh install of WordPress 4.9.5, and then installed version 2.3.9 of Cookie Consent, and version 7.1.3 of Wordfence Security. We then did the first three steps of the proof of concept for the supposed vulnerability using an Editor-level user (since that would be the lowest level user that would normally have the ability to take those steps):

1) Access WordPress control panel.
2) Navigate to the ‘Pages’.
3) Add a new page and insert the script you wish to inject into the page title.

Wordfence didn’t stop doing any of those steps. We set the script in step 3 to show an alert box that reads “Wordfence Security was supposed to stop this.”

Then logged in as Administrator-level user we completed the steps that could only be taken by them:

4) Now navigate to ‘Settings’ and select ‘Cookie Consent’.
5) Now click on the ‘Content’ tab.
6) Your injected script will now be executed.

If Wordfence Security didn’t prevent this from happening the message “Wordfence Security was supposed to stop this.” would be shown at step 5 and that is exactly what happened:

That is actually the correct result, but it wasn’t what someone that thinks they have some security knowledge believed and was telling others, which is a good reminder of the poor state of security recommendations out there. What makes it more striking is that it would have been easy to test this out, unlike so many other inaccurate claims that are made. If a claim is being made regarding security products and services without supporting evidence (which is true about almost all of them) it would probably be best to assume that it is false based on everything we have seen.