In Part One of our #AskSecPro series on WordPress Database Security, we learned about the anatomy of WordPress. Now that we have a firm understanding of the role the WordPress MySQL database plays in a WordPress installation, we can take a look at the various ways an adversary can exploit the mechanisms involved. We’ll also explore some of the ways to defend your database against compromise.
For the purpose of this article, I’ll focus on some of the things that most WordPress website admins have complete control over but probably aren’t configuring properly. Most of us are guilty of poor security practices at one time or another, and in ways we probably weren’t even aware of. In my best attempt to make this as dramatic as possible for a WordPress database security best practices article, I’m going to say that it’s time to start our recovery to be the best WordPress admins as possible. Consider this your twelve (or eight) step program to improve WordPress database security.
You’ve heard it a thousand times, but here it is again, always update your WordPress to the latest version. This is one of the most important steps you can take. To reiterate the significance of this step, it was recently discovered that over one million outdated WordPress websites were defaced this month from running versions 4.7 and 4.7.1. Keep WordPress updated. If you’ve turned off automatic updates, turn them back on!
It’s super simple, just download and open your WordPress installation’s wp-config.php file in your favorite text editor and add this line to it:
define( 'WP_AUTO_UPDATE_CORE', true );
Backups are another song that’s been sung more times than Sweet Caroline at a Red Sox game. We’re seeing more and more people adopt backup solutions, but I fear that databases are too often overlooked when considering backup solutions. The first thing you should do is have a conversation with your hosting provider to see what backup services, if any, are offered. If the available backup solutions do not include database backups, there are many WordPress-specific solutions that do. In addition to simply performing backups, you need to make sure that you’re performing integrity checks on those backups. If you’ve ever heard me speak at a WordCamp, you’ve probably heard the story about my dashcam and the Loop 101 UFO — the moral of the story was to perform integrity checks on storage.
If you’re not sure what to ask about, here’s a handy checklist:
While it is technically possible to run multiple applications, even separate WordPress installations, from the same database — don’t! There are numerous reasons you should never use the same database for multiple applications, not the least of which is a grossly ineffective security barrier. A vulnerability in one application could lead to the disclosure of the entire database. Remember that since no security methods are completely fool-proof, you should always be mindful of limiting the extent of any damage that could follow a compromise. One important part of this is effective barriers between applications and trust levels. These barriers serve to limit the damage, much like the watertight bulkheads of a naval vessel that help limit flooding between compartments. Think of the Titanic, you want the most effective bulkheads possible to keep your ship afloat.
Your wp-config.php file contains some previous information, including your unique hash salts as well as plaintext credentials for accessing your database with administrator privileges. Keep this file secure by ensuring the permissions on wp-config.php are set to 0600 (–rw––––––). This permission setting means that the owner can read and write to this file, but all others have no access. If you’re not familiar with setting file permissions, work with your hosting provider to accomplish this change.
Some hosting providers allow for remote connections to be made to SQL databases in their network. For the purposes of WordPress, this is not only unnecessary, it introduces additional risk to the database by allowing it to listen to requests from outside entities. Just like our parents told us not to talk to strangers growing up, we need to tell our database not to talk to untrusted sources. In most cases, your hosting provider can disable this option on your behalf.
Perhaps the most often overlooked password during password update day are database passwords. You never use them yourself, and you forget they exist. Well, your WordPress website uses these credentials every day. When updating your database password, make sure you’re also updating the connection string in your wp-config.php file to ensure WordPress is still able to connect to the database and avoid downtime. Your hosting provider should be able to assist you in finding how to update your database passwords.
/** MySQL database password */ define('DB_PASSWORD', '<strong>password_here</strong>');
While this is probably not the case for most people, you should go ahead and double-check that no additional database users have access to your WordPress database. I’ve seen a few cases where an unexpected database user was executing arbitrary SQL against a WordPress database and it was particularly hard to track down, because we don’t consider the possibility of another user. Double-check your database users and their privileges with your hosting provider to eliminate any stray users.
Scanning your website for malware and vulnerabilities plays a significant role in your overall security posture. While there aren’t currently methods for directly scanning your database contents for issues, you are able to scan the content the database feeds to your live website through an external scanner for both malware and vulnerabilities. Coupled with a robust file scanning solution, your defenses are considerably enhanced.
By following these WordPress database security best practices, you’ve become a better WordPress admin and a more effective guardian of the data in your website. Even in the worst of scenarios, the damage will be significantly limited by these precautions and recovery will be that much less stressful.