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?
2 Answers
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:
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.
