02.02.2022 | Author: Marcin Wiercioch
WordPress… WordPress everywhere: that is what today’s internet looks like. It is very likely that nothing will change here in the near future. What consequences and threats does this bring? Security definitely has to be taken seriously, because sooner or later every shortcoming will make us suffer.
There are several very important aspects on the server side to keep in mind.
The most popular way to access files on a server is the FTP protocol. Unfortunately it has limitations that make it simple to use on the one hand, but expose us to certain dangers on the other. Above all, there is no encryption of the communication, and passwords are sent as plain text.
We can quite easily increase the security of our system by using the SSH/SFTP protocol. The best solution is to add public key authentication to the encrypted connection. Then we do not have to worry about passwords leaking.
The topic of access rights to website files is broad, and several strategies can be used depending on the environment and our preferences as system administrators. First we need to define exactly what we want to achieve, and then introduce rules that match our needs.
The most popular configuration is one in which WordPress can install new plugins and updates. In that case we should give the user our web server runs as full rights to the files in the WordPress folder. Other users in the system should not be able to read them. This rule is not ideal, because it exposes us to the possibility of our website being infected through holes in the WordPress engine or, more likely, in plugins. So we have to be aware that the compromise we agree to gives us convenience but exposes us to risk.
A much safer solution is installing updates and new plugins manually, for example with WP-CLI. In that case it is enough for our web server to be able to write only to the /wp-content/uploads/ directory, where media uploaded by WordPress users are stored. For the rest of the file system, read and execute permissions are enough.
If we have administrative rights on the server, we should consider automatically scanning the WordPress directory to detect possible infections. There are a number of solutions on the market that can do this. One of the more popular is maldet.
There are many tools that work as WordPress plugins and perform a number of tasks to raise the security level of our WordPress. Users most often choose Wordfence, which has a huge number of useful options.
Remember, though, that plugins like this have to be configured correctly, because using them without proper understanding can cause many problems. The basic thing we should take care of is telling Wordfence how to determine our users’ IP addresses. If we use a reverse proxy such as Cloudflare, we must specify the exact header Wordfence should use.
We should also adjust the rate limiter and firewall settings.
Wordfence will detect suspicious user activity and block unwanted behaviour. Every so often it will also scan our application for malware, as well as for differences between the WordPress files installed on our server and those in the repository.
I encourage you to explore the whole range of features this plugin offers in its free and premium versions.
A perfectly secured application and server are of no use if users’ passwords fall into the hands of unauthorised people (or bots). We should pay particular attention to password strength. A very good practice is two-factor authentication. It can be implemented with relatively simple methods (Wordfence 2FA and Google Authenticator), and the effect significantly improves the security of access to the system.
To raise the security level, we can make a number of changes to our WordPress that limit features available “out of the box” but not used day to day.
By default, WordPress exposes a huge tool: the built-in REST API. It is very rarely used, though, so access to it should be restricted. Disabling this interface completely is not the best solution, because the admin panel uses it extensively. So what can we do to block access to the API for unauthorised people? The official documentation comes to the rescue: according to it, we can require authentication for every API call. Add the code below, for example to functions.php.
add_filter( 'rest_authentication_errors', function( $result ) {
// If a previous authentication check was applied,
// pass that result along without modification.
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
// No authentication has been performed yet.
// Return an error if user is not logged in.
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_not_logged_in',
__( 'You are not currently logged in.' ),
array( 'status' => 401 )
);
}
// Our custom authentication check should have no effect
// on logged-in requests
return $result;
});What is XML-RPC?
XML-RPC, or remote procedure calling, is an XML-based protocol for communication between systems. Many years ago WordPress implemented it to allow data exchange between blogs, external applications and so on. Today it has lost its importance and is practically not used. It is, however, very often the target of bots trying to break the system’s security with brute force or DDoS attacks.
How do you deal with it?
As a precaution, we should close this communication channel. The simplest way to do this is to add a rule to the .htaccess file
<files xmlrpc.php>
Order allow,deny
Deny from all
</files>Another WordPress vulnerability is so-called user enumeration, the possibility of obtaining a system username. Because WordPress was designed as a blogging system, it provides many features related to post authors. Unfortunately, this means a potential attacker can obtain a user’s login, and from there it is a short way to taking control of the website by brute force. To defend against this effectively, several modifications are needed.
This is a golden rule that applies not only to WordPress but to all web applications. It will protect us from many troubles hidden behind enigmatic abbreviations such as SQL injection, XSS and so on. It comes down to filtering all data that comes into our application from outside:
In WordPress, which has a built-in comment system, special attention should be paid to what users enter. If our template does not implement a comment form, it is best to disable commenting in the settings. This protects us from unwanted content being displayed on our website. This vulnerability has become one of the basic tools of spammers.
Finally, I suggest preparing a checklist that will serve as a tool for verifying websites before they go live. This way we will certainly not miss any important element of WordPress application security. You can start from our website launch checklist.
