Comment on Security: All WordPress Plugins Must Do This One Thing by Paul G..
Hi Olaf,
Thanks for your comment and sharing your thoughts on this.
Taking your first point, that it’s very dangerious that a plugin author has to decide which update is important? Can you elaborate and be more specific on that danger?
I believe in the article I expressed my own concerns about this, stating that plugin authors must be responsible in the updates they release as automatic updates. This is integral to the solution.
The alternative is what exactly? The only people, at least on WordPress.org that can release updates in the first place, are the plugin authors – that cannot be changed with the current system anyway. Someone has to decide. And at some point we must start trusting developers.
Yes, developers make mistakes, but I’d rather have the risk of mistakes than the risk of un-patched security issues.
Regarding the danger of one-click updates for plugins and themes, tools like iControlWP facilitate the bulk updating of plugins, themes and WordPress itself, but they remove your responsibility as a WordPress admin to vet and test all updates. That is something that we can hardly ever automate, though there are ways to get closer to that. But never have I, nor would I, advocate as you say “updates with eyes closed”. I’m not saying anything of the sort.
And yes, my advice is that WordPress plugin developers need to take responsibility for the security and safety of their plugins, and with the appropriate discipline, release security-only updates that are automatically patched on WordPress sites.
That is a very specific piece of advice and a place where I’d really love to reach. Your interpretation of what I’ve said however is much broader and not really reflecting my intent of the article. I’ll give the article a re-read and see if I can clear it up a bit further though.
Thanks for sharing your opinions on this – I appreciate you taking the time to do so – and sorry that you disagree with our views.
Cheers!
Paul.
Recent Comments by Paul G.
Security: Hide The WordPress Login and Admin Pages (wp-login.php)
Hey Rob,
Brilliant news… Glad it’s working so well for you!
Part 5: Ultimate Comment SPAM Killer – Shield WordPress Security Plugin
Why does WordPress need to do that? I’ve no idea… that’s the way the author of this particular code decided to implement this. 🙂
My approach is to take each “spam” word/pattern and I use “stripos()” on each item of the comment that needs to be checked.
The truth is that efficiency isn’t hugely important in this area because it’s only run when a comment is posted. I could probably optimize my approach too, but again, it’s not critical.
Further reading: http://lzone.de/articles/php-string-search.htm
Part 4: Login Protection – Shield WordPress Security Plugin
There’s nothing you can do about that unfortunately if the bots are cracking away at your page. Most bots would get blocked by the automatic blacklist if they’re repeatedly hitting you with this.
As to XML-RPC, we have a couple of options ranging from by-passing the login/user sessions systems to completely disabling it:
https://www.icontrolwp.com/2015/10/automatically-block-brute-force-amplification-attacks-against-wordpress-xmlrpc/
Further WordPress Admin Access Lockdown
Eileen, Lynn,
The automatic updates system is WordPress-controlled and run on a WordPress cron. The Security admin access shouldn’t affect this. If you have enabled automatic updates, but restricted the system using the admin access and you find it’s not working as it should, please let me know in the support forums.
To your first question, if you enable this Security Admin system and lock-down any features, then you must, as an administrator or not, authenticate with the Security Admin system before you can make changes to the zones that have been restricted.
Let me know if it’s still unclear and I’ll elaborate further on areas you need.
Thanks!
Part 5: Ultimate Comment SPAM Killer – Shield WordPress Security Plugin
This is something that you’ll have to test with your particular installation(s) and configuration. Aggressive page caching will probably affect this functionality, but that is the double-edged sword that is “caching”.
I’d be interested to hear what you find with your tests.
Thanks!
