This plugin has a worryingly high CodeRisk RIPS score

Relying on a black box security score to determine whether you should use a plugin doesn’t seem like a good idea in general. In this case not only does the company behind it not have a great understanding of security based on what we have seen in the past, but another plugin that has what would probably be described as a moderately serious vulnerability in its current version, which is flagged as a possible issue by another automated tool, gets a score of 0 with this tool, so the results don’t seem all that reliable.

In regards to database queries, in our checking we only found that there were only five that could run (one more is commented out) and all them look to be properly secured using prepared statements, so there doesn’t appear to be any issue in that regard or any reason to change the plugin’s usage of database queries.

> Relying on a black box security score to determine whether you should use a plugin doesn’t seem like a good idea in general.

I agree to a certain degree. That is the reason why the maintainer of the plugin has access to the full results. I would only think about abandoning a plugin with a high score if it was already abandoned by its maintainer. This is also what we recommend to do in the info text on CodeRisk.

> In this case not only does the company behind it not have a great understanding of security based on what we have seen in the past

I am not sure where you get this from but we have found many critical vulnerabilities in large applications and plugins in the last years. You can find some of them here https://www.ripstech.com/security-vulnerability-database/ but the smaller ones (which are many more) are not even listed.

> In regards to database queries, in our checking we only found that there were only five that could run (one more is commented out) and all them look to be properly secured using prepared statements, so there doesn’t appear to be any issue in that regard or any reason to change the plugin’s usage of database queries.

Yes, the reason for that is that it was not a SQL injection that was discovered. And the finding does look valid to me. We will create a PR with a fix next week.

Also, your blog post is full of misinformation, pluginvulnerabilities. CodeRisk might not have picked up a vulnerability, that is a possibility, we also write that on the site, but this does not lower the significance of a high score. On the other hand we have found many real vulnerabilities in WordPress plugins that are not picked up by your tool. Does that mean it is completely useless?

You can also compare the risk timeline of CodeRisk to public vulnerabilities that are published on https://wpvulndb.com/ and you will see that most of the time (not always!) the risk score decreases if a vulnerability was found and fixed.

Regarding my comment about the number of queries, that was less of a security comment and more of an optimization thought. There may only be 5 queries in the plugin, but it appears to be based on the number of taxonomies. On my test site I saw 23 queries performed by this plugin, and on more complex websites I’ve seen it go well above 100.

This may not be something that is avoidable as the feature provided by this plugin may need each one of those, but again that is a convenience feature and is why it plays into the overall decision.

On the security notes, I ran one of my old plugins through CodeRisk and it found that 1 of the 4 issues was an XSS risk, so I so think there is validity in their score. At the very least it implies that there is something that can possibly be improved, and that is worth researching in my opinion.

• This reply was modified 6 years, 7 months ago by GreatBlakes.

Thanks, GreatBlakes! And just to leave no room for misunderstandings, the other 3 issues that are not XSS did not influence the risk score. We have disabled code quality issues for the score but enabled them for the results that the maintainers can see.