Protecting Against Unpredictable Behavior In WordPress Plugins
Securing Plugin Data Access
Plugins can sometimes access, modify, or delete data in unexpected ways that compromise security or data integrity. As the WordPress site owner, you need to proactively limit how plugins can access sensitive information stored in the database.
Limiting database access with user roles and capabilities
The WordPress role and capability system allows granular control over what plugin code can do on your site. Certain roles like Administrator traditionally have unlimited capabilities. This means any plugin activated by an Admin could potentially access, modify, or delete any database data without restriction. To prevent this, use a plugin like User Role Editor to customize roles and capabilities. For example, you can deny the dangerous unfiltered_html and unfiltered_upload capabilities globally. Or make custom roles for your plugin and content authors that only have permissions for safe plugins. These restrictions configure the WordPress privilege system to better protect your database information.
Sanitizing and validating plugin input data
Any data submitted to your site through plugins could be malicious. WordPress has functions like esc_sql() and sanitize_text_field() to clean dangerous characters from strings. However, improper sanitization is a common plugin vulnerability. Whenever you activate a new plugin, review the code to ensure all input data is escaped before ending up in SQL queries or OS commands. Sanitization functions should be used for POST, GET, SERVER, and COOKIE data. You may also patch old plugins yourself to add extra validation and sanitization not built-in originally. Having this protection prevents external data from manipulating or destroying your site’s back-end.
Using nonces and authentication to protect AJAX calls
Plugins frequently use AJAX callbacks to WordPress admin-ajax.php to modify content dynamically. While convenient, improperly protected AJAX is an easy backdoor for attackers. WordPress nonces provide one-time use authentication tokens before sensitive operations. Upon activation, check each plugin using jQuery.ajax() or the WordPress AJAX API. Verify proper nonces are checked with check_ajax_referer() before allowing database edits or POST information manipulation. For best security, disallow admin-ajax.php requests originating from third-party domains with CORS domain whitelisting. An additional layer of authentication requiring valid user sessions before AJAX calls can prevent session hijacking or replay attacks aimed at plugins.
Guarding Against Plugin Code Execution
Granted filesystem permissions allow plugins to potentially execute malicious code on a web server. Minimize exposure by restricting executable paths and permissions.
Disabling PHP execution in uploads and content
Uploaded files or content entered via plugins could contain executable code if planted by attackers. This dangerous PHP code injection gives them a backdoor to compromise your site. Disable PHP execution in key directories like /wp-content/uploads/ by adding this line to wp-config.php:
define( 'DISALLOW_FILE_MODS', TRUE );
Alternatively, harden file permissions with:
$ chmod -R 444 /wp-content/uploads
These restrictions prevent uploaded or plugin-submitted files containing hacker code from executing. However, legitimate plugins functionality may break if they rely on loose uploads directories permissions. Only activate community plugins from reputable developers that follow the WordPress guidelines.
Setting proper file permissions on plugin files
Weak permissions on plugins themselves also raise security issues. The default umask value of 000 grants new files complete read/write/execute access. Instead, add the following to wp-config.php:
umask(0002);
New plugins then correctly get a maximum umask value of 775 (rw- rw- r–).
Additionally, run:
$ chmod -R 644 ./*.php
in the /wp-content/plugins/ directory to apply stricter permissions. These steps prevent malicious or vulnerable plugin code from having unnecessary executable permissions if hacked. However, it could break functionality in plugins relying on loose permissions incorrectly.
Using Suhosin or security-focused PHP configs
At the PHP level, further lock down plugin capabilities to limit potential exploits of dangerous functions. If running PHP 5.2 or older, the Suhosin hardening patch adds many protective restrictions including:
– Disabling dangerous PHP functions
– Bounding array sizes
– Blocking phar archive execution
– Whitelisting permitted classes
On newer PHP versions, these same Suhosin protections are partially available via hardened configuration:
max_input_vars = 1000 max_input_nesting_level = 64 disable_functions = "exec,passthru,shell_exec,system" allow_url_fopen = Off allow_url_include = Off
With these configurations in php.ini or at runtime, old or vulnerable plugin code simply cannot execute more dangerous operations. That significantly raises the bar for plugins to damage your site. However note again properly written plugins may malfunction without the ability to call certain built-in PHP functions.
Monitoring Plugin Behavior
Runtime visibility into how each plugin interacts with WordPress core, the database, other plugins, the filesystem, and server resources reveals unseen activity. Use that insight to detect errant behavior demanding investigation or plugin removal.
Enabling debug logging and obscuring credentials
In wp-config.php, add:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('log_errors','On');
@ini_set('error_log','/my/path/debug.log');
This captures all PHP warnings, notices, and errors to a debug.log logfile for analysis. However, take care to obscure any database credentials or API keys logged. A simple define() can mask those. With logging enabled, abnormal plugin behavior gets recorded for security auditing and issue diagnosis.
Tracking disk space usage, CPU load, and memory
Plugins interacting with filesystem paths or making excessive database queries can trigger resource contention issues. Monitor overall site disk space, CPU load averages, and memory usage for stability at times of peak traffic. Any outlier plugins causing resource exhaustion then become obvious for troubleshooting. Many great server monitoring tools like Monit can track this telemetry and send automatic alerts.
Watching admin notifications and alerts
While plugins may behave normally for end users, behind the scenes they could still experience problems. New WordPress administrator alerts, success messages, or errors often reveal such hidden malfunctions. So carefully watch the dashboard notifications after activating new plugins. Google any ambiguous plugin messaging to check if others report it indicating larger issues. With this user-facing monitoring, detect and deactivate plugins that internally generate warnings.
Hardening the WordPress Environment
An incredible diversity of plugins exists across thousands of developers with varying security practices. The overall integrity and protectiveness of your WordPress environment itself counters poorly-coded plugins.
Keeping WordPress and plugins updated
Core WordPress, themes, and plugins receive constant security patches resolving newly discovered vulnerabilities. Unfortunately, many sites operate with outdated software containing dozens of publicly known exploits. Upon activating new plugins, immediately check the Version column of the plugin list. Any out-of-date plugins lacking recent support may still contain easy remote code execution or SQL injection issues fixed years ago. Click Check Again under Dashboard → Updates to install available security fixes. Sign up at WordPress.org to receive vulnerability notifications impacting your specific site configuration. Scheduling regular automated WordPress updates is wise.
Using only reputable commercial plugins
Commercial plugins sold via marketplaces like CodeCanyon undergo code review and compatibility testing. Such vetting offers reasonable assurance against malware behavior, even if features evolve after purchase. Strictly choosing paid commercial plugins routes around the common neglect and copy/paste coding of amateur free plugins. Favor these commercial plugins within WordPress admins instead of unaccountable hobbyist developers. Your visitors expect professionalism anyways behind custom site features.
Running scheduled vulnerability scans
Despite best efforts proactively hardening plugins, unknown zero-day exploits still arise. Frequently scan your WordPress site using automated web vulnerability scanners to discover newly reported issues. Free scanners like WPScan or commercial services from Sucuri, WordFence, or NinTechNet hunt for every plugin coding mistake or backdoor allowing site infiltration. Addressing these identified vulnerabilities through updates, disable plugins, or uninstalls is vital for preventing data loss or service interruption in an age of sophisticated hacks against weaker sites.
