Once, I had a problem that somehow someone managed to change files of my website without FTP or SSH credentials. Probably he got in through WP (probably it wasn’t a ‘he’, but an ‘it’, a bot), we said after investigation.
Anyway, since then I’m using the WordPress File Monitor plugin, which mails me when files are changed. Now, when I update plugins or themes, I first perform a scan with the file monitor, then I update and then I scan again. The monitor gives an alert because of the update, and I remove it, because ‘it’s because of the update’.
Now I’m wondering, if WP is especially vulnerable when updating (for example, if it would be possible that the update doesn’t come from the WP servers but from a hacker), then with this I open a leak in the security of my site.
On the other hand, if the updated plugins / themes work (which I always check), and it’s only the files of the plugins that are changed (which I also always check), then it’s -in my opinion- not so likely that someone hacked my site during the update.
Am I doing the correct thing here, or should I check better after updating?
What you’re doing at the moment is okay, but there are far far better ways to do it.
The problem of man in the middle attacks here is that to insert yourself between wordpress.org and a server at a data centre is no easy task, so this scenario is very unlikely.
However
If you abandon the built in updater and instead rely on git repositories to pull down your data, then you can guarantee 100% that your plugins and themes are secure, even if a man in the middle attack occurs.
This is because of the reliability promises git makes. A git repository has an SHA-1 hash which represents its VCS history, and any attempt to ‘meddle’ or manipulate a git repository to add code will invalidate that hash, causing git to balk. Because of this, so long as that hash is good, you can pull code changes down from anywhere, no matter how untrustworthy thanks to the cryptographic guarantee.
Here’s Linus Torvalds talking about trust and reliability in Git far better than I could explain:
http://youtu.be/4XpnKHJAok8?t=56m10s
Once you’ve moved to a version controlled setup, you can set your wp-content folder etc to read only for the servers Apache/WWW/Nginx user. Should a non-git repository be corrupted or compromised, you can simply re-checkout the repository in place and undo the damage.
Provisioning/deployment tools such as Composer would also be useful here.
Note that while Git would prevent a man in the middle attack by highlighting the data inconsistencies and providing evidence of tampering, it will only guarantee you have the correct copy of the source. It doesn’t prevent the original developer from having a nervous breakdown and putting a DROP ALL TABLES command in their plugin. For that we have testing in sandboxes, proofreading/code reviews, and support forums.
Your update is as secure as a weakest point in your update chain. Since upgrade are done via HTTPS since 3.7 a MITM attack against wordpress.org will be so hard it is not worth your time to even consider protecting yourself against it as anyone with the resources for that will get you in one way or another.
The more problematic points are actually the accounts in wordpress.org and your account on your server. You can protect your server but you can’t protect against hacking of the wordpress.org accounts and inserting malicious code in plugins and themes that you use.
Only way to be totally sure what you update the site with is by manually uploading the files to the server after you have checked them.
Side note: if files on your server where changed without ftp or ssh access then your server is not secure enough and you probably not isolating your Apache as a different user and setting the right permissions on your directories.