Who checks the WordPress plugin directory for malicious code?
After reading this article earlier stating some quick points on how to get your plugin removed from the directory, it made me think a little about how often we check the plugins we install.
Mark Jaquith (the author) covers just ten things that should not be done, from incompatible licenses to harvesting email addresses.
The problem is, how can you test for these things? As a developer it’s quite easy just to open up the files to have a scan over how it works and see what it does.
But what about those people who have little understanding of the code behind it all? I can only assume that they put 100% trust in anything they install.
Other than having a team of people which manually trawl through the directory and approving plugins, there isn’t much of a solution.
With the number of plugins available and the frequency of updates this would be an impossible task, so what could be done?
One possible option would be to write an additional plugin that scans the plugins folder and counts and explains all the different hooks used.
It could also carry out some additional checks to see if there was either use of the mail function, dropping of any tables or permission changes.
This isn’t an exhaustive list of things to do or check for, but as it’s unlikely that I will find time to write such a plugin the list stops there – ready for someone else to pick-up on the idea, unless of course something already exists? 
The same can be said for any software in general. Closed-source being the hardest to be sure of.
With any software you have to place trust in the source, whether its dodgy-twitter-plugin or apache, though I guess your point being that its easy for someone unknown to make a plugin and get it downloaded.
What you can do at least with WordPress, with extensions like suhosin, is lock it down so that a rogue plugin can’t download any additional code and execute it.
This can be done by disabling eval function (suhosin.executor.disable_eval), remote includes (allow_url_fopen) and disabling inclusion of writable files (suhosin.executor.include.allow_writable_files)
This way at least only the code you and the community can see is executable.
[...] Read the original post: Who checks the WordPress plugin directory for malicious code … [...]
This does sound like another possible solution, but not for the audience I was really aiming to help.
I think what I was ultimately trying to say was “What can be done to help ‘regular’ WordPress users check for malicious plugins?”.
The only thing I could really think of that didn’t involve touching anything server side would be to create something they could install and see on the front end.