WordPress sites are infamous for their security flaws, and are frequently the subject of a WordPress hack. It could be due to the developer’s lack of security competence or the use of one of the many plugins available (of which the security cannot be guaranteed).
It’s no wonder that WordPress is a popular target for both experienced hackers and script-kiddies, as it powers one out of every five websites on the Internet. Around 90,000 WordPress sites were hijacked in 2013 and used as part of a botnet. They’re also a popular malware target.
This is why we’ve taken the effort to outline certain steps that may be performed to solve some of the most prevalent security flaws or malpractices found in hundreds of WordPress sites, which can assist prevent a WordPress hack.
Running the Latest Version of WordPress
Using the most recent version of any software is arguably the most obvious security precaution to take. However, with over 86 percent of WordPress installations running out-of-date versions, this is still an important point to make.
Each WordPress update brings with it new features, but it also brings with it bugfixes and security fixes, which help your WordPress site stay safe from common, easy-to-exploit vulnerabilities.
Running the Latest Versions of Themes and Plugins
Running the most recent version of WordPress isn’t enough; your site’s plugins and themes may contain vulnerabilities that damage the security of your WordPress site, exposing it to a WordPress hack.
The Slider Revolution plugin is an excellent illustration of how out-of-date plugins and themes can jeopardise the security of your website. Slider Revolution is a popular WordPress plugin that is also used by many of the WordPress themes available on the Envato Market. The flaw in the plugin allows malicious users to gain database passwords, potentially allowing entire control of the WordPress site via the database.
As a result, it’s critical to ensure that all of your themes and plugins are up to date. You can ensure that your site is protected with the latest security patches by keeping your plugins and themes up to date. Acunetix runs WordPress security scans, detecting WordPress installations and launching version-specific security checks to ensure your website is safe.
Be Selective When Choosing Plugins and Themes
Thousands of plugins and themes are available for WordPress, allowing you to extend and modify your site. While it’s crucial to expand your site’s capabilities and customise it, it shouldn’t come at the expense of its security.
Even if your WordPress installation, plugins, and themes are all current, your site may still be exposed to attack. Plugin enumeration allows attackers to see which plugins are installed on your WordPress site. By avoiding the installation of superfluous plugins, you will instantly reduce the attack surface of your website.
Be judicious when deciding which plugins and themes to employ. Read up on a plugin or theme before installing it (preferably from sources other than the plugin/theme developer’s site). This stops malware like the Tools Pack malware plugin from being installed.
Check how many people have downloaded the plugin or theme and when the writers last updated it. The more downloads and recent updates a plugin or theme has, the more widely it is used and actively maintained by its writers, implying that if a vulnerability is discovered, it will be addressed quickly.
Remove Inactive Users
Maintaining inactive users on your WordPress site expands the attack surface. Users, particularly Administrators and those with the capacity to alter material, are likely to be one of a site’s weakest spots because, sadly, the majority of users select weak passwords.
If you absolutely must keep inactive users in your WordPress database, set their role to “Subscriber” to limit the actions they can take.
Security Configurations – Prevent Directory Listing
Please be aware – The following may damage certain functionality depending on your webserver’s settings, active plugins, and/or themes. Before changing any configuration on production servers, it is strongly recommended that you test it out in a testing/staging environment.
When the web server cannot find an index file (such as index.php or index.html), the server will display an HTML page detailing the contents of the directory if directory listing is enabled.
By disclosing information that can be utilised by an attacker looking to exploit a vulnerability in a WordPress plugin, theme, or even the web server itself, this information could leave a site open to attacks.
While disabling directory listing is not a WordPress-specific security measure, directory listing is enabled on several WordPress sites operating on Apache HTTP Server default installations.
You’ll need to add the following settings to your WordPress site’s.htaccess file (which is normally located in the root directory) to prevent directory listing in Apache HTTP Server.
Complex Security Keys
Please be aware – The following may damage certain functionality depending on your webserver’s settings, active plugins, and/or themes. Before changing any configuration on production servers, it is strongly recommended that you test it out in a testing/staging environment.
WordPress employs a series of Security Keys that are long, random, and complex. These keys are made up of a combination of encryption keys and cryptographic salts.
Security Keys ensure better encryption of information stored in the users’ cookies. There are a total of eight security keys that WordPress uses – AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, and NONCE_SALT.
A Security Key works in the same way as an extremely strong password or passphrase, and it should include characteristics that make it more difficult to generate enough options to crack. Cryptographic salts are also used by WordPress Security Keys to improve the security of the generated output.
You have the option of creating your own random keys or using WordPress’ online key generator. Simply copy the keys created by the generator and put them into your wp-config.php file.
Restrict Access to wp-admin Directory
Password-protecting your WordPress admin area with a layer of HTTP authentication is a good way to keep attackers from guessing users’ passwords. In addition, if an attacker manages to obtain a user’s password, they will need to bypass HTTP authentication to access the WordPress login form.
In Apache HTTP Server, you can achieve this by creating a .htpasswd file and adding a few configuration directives described below.
The .htpasswd file stores combinations of usernames and password hashes which the web server will use to authenticate users. You can create a .htpasswd file using the htpasswd command line or using an online password file generator.
Several Linux distributions install the htpasswd utility together with Apache itself, however, most Debian and Ubuntu users will need to install the apache2-utils package as follows.
apt-get update
apt-get upgrade
apt-get install apache2-utilsOnce htpasswd is installed, run the following command to create a new .htpasswd file with a single user. The following command will create a new .htpasswd file located at /srv/auth/.htpasswd with a username of myuser. htpasswd will then prompt you to enter and then confirm the password of your choice.
htpasswd -c /srv/auth/.htpasswd myuserNote: It is strongly advised against storing.htpasswd files in a publicly accessible directory.
By default, Apache does not serve any files with the.ht prefix, however this should not be assumed.
To enable basic HTTP authentication in the WordPress admin area, activate the directive specified below in the wp-admin directory and refer to the previously created.htpasswd file. In the appropriate Directory> section of your server’s Apache configuration file, or in an.htaccess file within the wp-admin directory, add the following lines.
AuthType Basic
AuthUserFile /srv/auth/.htpasswd
AuthName "WordPress Authenticated area."
Require valid-userThe AuthType directive is specifying that the authentication type. In this case, Basic authentication is being configured.
The AuthUserFile directive specifies the full path to the .htpasswd file. This file is the file that shall be used to store password hashes which the server shall later use to authenticate users with.
The AuthName directive contains an arbitrary message which the browser will present to the user upon authentication. The Require valid-user setting simply instructs Apache to allow any valid user to authenticate.
Note: While this file can be stored anywhere on your computer, we highly advise against storing it in a web-accessible location. In most Apache default configurations, all files beginning with.ht are not web-accessible by default, although this should not be expected.
Disable File Editing
WordPress admin users can change PHP files of plugins and themes inside the WordPress admin interface by default.
Because this functionality provides code execution on the server, it is generally the first thing an attacker looks for if they obtain access to an administrative account.
By adding the following constant to wp-config.php, editing from the administrative interface is disabled.
define('DISALLOW_FILE_EDIT', true);
Prevent WordPress Username Enumeration
It’s easy to count WordPress users using an author’s archive page in many WordPress blogs. If WordPress permalinks are enabled and the user has written one or more posts, this will work.
In the article WordPress Username Enumeration using HTTP Fuzzer, you can learn more about WordPress Username Enumeration.
You may prevent WordPress Username Enumeration by adding the following rule to your website’s.htaccess file (which is normally located in the root directory).
RewriteCond %{QUERY_STRING} author=d
RewriteRule ^ /? [L,R=301]
Enabling HTTPS for all logins and wp-admin
HTTPS is, strictly speaking, not a protocol in and of itself, but rather HTTP wrapped in TLS/SSL. TLS, or SSL as it is more generally known, encrypts data being communicated and authenticates the identity of a server for websites and web applications.
HTTPS is most commonly associated with shopping carts and online banking, but it should be utilised whenever a user sends sensitive data to a web server or vice versa.
Depending on the site’s traffic, TLS/SSL may require a large amount of server resources. As a result, most websites do not need to serve their full content over HTTPS. The login form and admin section of a WordPress site, on the other hand, are undoubtedly the most sensitive parts of the site. As a result, it is strongly recommended that TLS/SSL be not just implemented, but also enforced in certain places.
On both the wp-login and wp-admin pages, WordPress makes it simple to enforce TLS/SSL. This is accomplished by specifying two constants in the wp-config.php file of your website.
Note - You must already have TLS/SSL configured and working on the server before your site will work properly with these constants set to true.
To ensure that login credentials are encrypted during transit to the web server, define the following constant in wp-config.php.
define('FORCE_SSL_LOGIN', true);
To ensure that sensitive data in transit (such as session cookies) is encrypted when using the WordPress administration panel, define the following constant in wp-config.php.
>define('FORCE_SSL_ADMIN', true);
Restrict Direct Access to Plugin and Theme PHP files
For a variety of reasons, allowing direct access to PHP files is risky. Some plugins and theme files may include PHP scripts that aren’t meant to be called directly because the file would be calling functions defined in other files. This may cause the PHP interpreter to display errors or warnings, potentially exposing personal information.
Another reason to limit direct access to PHP files is to prevent attackers from circumventing or ignoring security measures (such as authentication) when code is divided into smaller files (which will then be included and used together with other code)
Some plugins and themes break down code into smaller files and then include these smaller files in larger code chunks. An attacker may be able to directly call one of the smaller files, bypassing numerous security safeguards such as input validation checks. Most of the time, this happens because the validation isn’t completed in other files or in the smaller modules indicated.
Furthermore, with direct access to a PHP file and the register globals directive enabled on the server (the directive is disabled by default in PHP versions 4.2.0 and higher), an attacker may be able to carry out a variety of malicious actions, including the ability to define PHP variables from GET/POST requests and bypassing various protection mechanisms.
The great majority of plugins and themes do not require users to make direct HTTP calls to PHP files, however if this is the case, you can whitelist files and directories that require direct access to PHP files. Any direct queries to PHP files will be redirected to a page of your choice by the following rule (in the following example the server will respond with a 404 page and status code).
# Restrict access to PHP files from plugin and theme directories
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/file/to/exclude\.php
RewriteCond %{REQUEST_URI} !^/wp-content/plugins/directory/to/exclude/
RewriteRule wp-content/plugins/(.*\.php)$ - [R=404,L]
RewriteCond %{REQUEST_URI} !^/wp-content/themes/file/to/exclude\.php
RewriteCond %{REQUEST_URI} !^/wp-content/themes/directory/to/exclude/
RewriteRule wp-content/themes/(.*\.php)$ - [R=404,L]
Prevent PHP files from Executing
Because WordPress sites require users to be able to contribute new content, the upload directory must be readable. Your wp-content/uploads directory should be considered a potential entry point to this extent.
The uploading of PHP files poses the greatest risk. Although the WordPress administration panel does not allow users to upload PHP files, it is possible that a plugin or theme will allow file uploads without utilising the WordPress APIs. This might lead to the upload of a malicious PHP file, which would then be run on the server.
The easiest way to avoid this potential security issue is to use the following rule to prevent the web server from providing any PHP files in the wp-content/uploads directory.
<Directory "/var/www/wp-content/uploads/"> <Files "*.php"> Order Deny,Allow Deny from All </Files> </Directory>
Secure Your Debug Logs
Developers or system administrators can activate debug logs to log any PHP issues that occur during the creation of plugins or themes, as well as during the deployment of a WordPress site.
The WP DEBUG constant, declared in wp-config.php, is used by WordPress. Throughout WordPress, the constant is used to activate the debug mode. By default, the constant is set to false.
WP DEBUG LOG and WP DEBUG DISPLAY companion constants can also be enabled by developers and admins. WP DEBUG LOG creates a log file in the wp-contents folder, whereas WP DEBUG DISPLAY determines whether or not debug messages are displayed within the HTML of pages.
While any of the above will be valuable while a theme, plugin, or site is being developed, enabling them on a live website may result in information leakage, allowing malicious users to read faults and more logging data. On production systems, the WP DEBUG constant should be disabled by removing it from the wp-config.php file or setting it to false as follows.
define( 'WP_DEBUG', false );
The 13 tips listed above should help you avoid a WordPress hack. Acunetix can automate WordPress security processes by scanning for over 1200 vulnerable WordPress Plugins & Misconfigurations, testing for weak WordPress admin passwords, enumerating WordPress usernames, detecting malware masquerading as plugins, and more.