When we began providing service for WordPress sites last year, we didn't know the WordPress community or market very well. Since then we've brought on thousands of WordPress sites, and have been able to interact with hundreds of developers to talk about their joys, their pains, and their ambitions. We've learned a lot.
One of my takeaways from the past year is is that security is an existential question for WordPress, especially as it moves up-market into more complex and higher-profile projects. It's probably the biggest thing holding back wider up-market adoption.
While "vanilla" WordPress already has decent security, core alone can’t really satisfy custom site requirements. Most of the value of WordPress as a CMS is the ability to leverage open source plugins, and to use its core APIs to develop custom functionality and design. This is where the security story requires some deliberate thinking. Never fear, though; Pantheon has answers.
Hardening WordPress: When Should a Website Update Itself?
If you’re just running plain old WordPress, the auto-updater is your friend. Set it and forget it. However, if you’re reading this blog post, it’s a near certainty that you are building sites with custom design and functional requirements that go beyond what “vanilla” WordPress can deliver. At this point, WordPress’s self-updating capabilities become a double-edged sword.
For instance, one obvious downside is that sometimes a core update will break things. You'd probably like to be able to test an update before it goes live rather than having a surprise fire drill or panicking client on your hands. On the other hand, WordPress’s ability to install plugins and themes directly from the wp-admin interface (or wp-cli) is great for developer productivity.
But from a security standpoint, these capabilities represent serious risk. They require system privileges: the CMS must have to have write access to its own code. This is one of those "with great power comes great responsibility" situations.
The trouble is that once the website can alter its own code, the potential exists for malicious actors to trick it into adding code that shouldn't be there. Security issues with popular plugins commonly come back to this capability. Strange-looking PHP files start showing up, and the next thing you know your system has been hijacked.
This is classic "privilege escalation"—the ability to abuse a web form to drop a PHP file onto the application server—or append code to an existing file—turns into a beachhead for further incursion. Hardening WordPress against this kind of incursion is a must-have for any installation of consequence.
Much like we saw with the SQL-injection attacks after Drupageddon, these initial exploits usually don’t do anything in and of themselves. They’re “back doors”, waiting for a subsequent HTTP POST to deliver a "payload" to execute. The next step is to use this backdoor to install a rootkit or spam gateway, host malware, or hijack site traffic via redirects.
Unfortunately, the only way to prevent this for sure is to harden your installation by eliminating WordPress's ability to self-update, at least in production. The trick is figuring out how to lock things down without killing your developer productivity.
Staying Agile While Locking Down Live
On Pantheon, we allow developers to have free reign in their own space. Every site has a Dev environment, and teams of developers can use Multidev to collaborate across several. These areas—which themselves can be protected with HTTP-Auth—are safe places to add code, run updates, etc, including using wp-admin.
Changes to the codebase here are tracked by the dashboard, and can be turned into a Git commit with the click of a button. This creates a “chain of custody” for all changes. They can be shared with other developers, or moved to the Test environment for final review before going Live.
In the Live environment, the website only as access to write into "wp-uploads", and furthermore PHP execution is banned within that whole directory structure. Even if there's a plugin vulnerability, and a malicious user manages to put "backdoor.php" in there, no further exploit is possible.
This also has the benefit of limiting potential damage from human error. Your client can’t install extra plugins without your knowledge, or crash the site by accidentally using the template editor to insert a syntax error into some theme template.
For custom projects, we believe our workflow provides the best of all possible worlds: a secure live website, freedom for developers to operate, and a standardized, structured way to review changes before they go live. This is the kind of value a website management platform brings to WordPress, and we're happy to be helping WP devs use these capabilities to take on more complex and challenging use-cases.Topics: WordPress Hosting, Website Technology, WordPress