Did you know that more than 73 million web sites in the world run on the WordPress publishing platform? This makes WordPress more popular than Microsoft SharePoint, Blogger, or Drupal. It also means that WordPress is a large target for hackers.

Half of the WordPress sites out there are self-hosted, which means that the WordPress administrator carries the lion's share of responsibility for a secure installation. Out of the box, there are several ways that WordPress security can be tightened down, but only a fraction of sites actually do so. This makes WordPress an even more popular target for hackers.

The following five strategies can help any WordPress installation become significantly more secure, and raise awareness of the types of vulnerabilities to defend against.

Vulnerability # 1: SQL Injection & URL Hacking.

The problem: WordPress is a database-backed platform that executes server-side scripts in PHP. Both of these characteristic can make WordPress vulnerable to malicious URL insertion attacks. Commands are sent to WordPress via URL parameters, which can be abused by hackers who know how to construct parameters that WordPress may misinterpret or act on without authorization.


SQL injection describes a class of these attacks in which hackers embed commands in a URL that trigger behaviors from the database. (SQL is the command language used by the MySQL database.) These attacks can reveal sensitive information about the database, potentially giving hackers entrance to modifying the actual content of your site. Many of today's web site defacement attacks are accomplished by some form of SQL Injection.

Other versions of URL hacks can trigger unintended PHP commands which, again, can lead to injecting malware or revealing sensitive information.

The defense: Most WordPress installations are hosted on the popular Apache web server. Apache uses a file named .htaccess to define the access rules for your web site. A thorough set of rules can prevent many types of SQL Injection and URL hacks from being interpreted.

The code below represents a strong set of rules that you can insert into your web site's .htaccess file that will strip URL requests of many dangerous attack injections:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\:  [NC,OR]
RewriteCond %{QUERY_STRING} http\:  [NC,OR]
RewriteCond %{QUERY_STRING} https\:  [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(&#x22;|&#x27;|&#x3C;|&#x3E;|&#x5C;|&#x7B;|&#x7C;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

 

Vulnerability # 2: Access to Sensitive Files.

The problem: A typical WordPress install contains a number of files which you don’t want outsiders to access. These files, such as the WordPress configuration file, install script, and even the “readme” file should be kept private.

The defense: As with preventing URL hacking, you can add commands to the Apache .htaccess file to block access to sensitive private files. For a typical WordPress installation, the following code will block access to directory listings, plus a set of specific files related to WordPress and the Web server itself.

Options All -Indexes
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>
<files fantastico_fileslist.txt>
Order allow,deny
Deny from all
</files>
<files fantversion.php>
Order allow,deny
Deny from all
</files>

 

Vulnerability # 3: Default Admin User Account.

The problem: Many default WordPress installs include an administrator user account whose username is simply “admin”. Hackers may try to log into this account using guessed passwords.

The defense: Any element of predictability gives hackers an edge. Although a hacker would still need to guess or brute-force your password to access the admin account, you are even more secure without an “admin” account at all.

Instead, log into WordPress and create a new user with an unpredictable name. Assign administrator privileges to this user. Now delete the account named “admin”. A hacker would now need to guess both the username and password to gain administrator access, a significantly more challenging feat.

Vulnerability # 4: Default Prefix for Database Tables

The problem: The WordPress database consists of numerous tables. In many WordPress installs, these tables are named with a default prefix that begins with “wp_“. For hackers, the ability to predict anything can provide an extra advantage.

The defense: Changing the prefix of your WordPress tables can eliminate this predictability. Some security experts argue that this will not stop a savvy hacker who can use other means to determine the table names in your installation. While this is true when talking about a knowledgeable hacker, many amateur hackers use pre-packaged scripts to perform their dirty work and these are more likely to be successfully blocked by eliminating predictable table names.

When setting up a new WordPress install, you can specify the database table prefix yourself. This gives you the opportunity to choose something unique and unpredictable. If WordPress is already installed, you can retroactively change the table names. Although this can be done manually, the process requires directly manipulating the database in several places.

An easier way to change table prefixes for an existing WordPress installation is by using the plugin named Better WP Security. This plugin contains several defenses including some discussed elsewhere in this article, with a simple point-and-click interface to change your table names to include a randomly-generated prefix.

Vulnerability # 5: Brute-Force Login Attempts

The problem: Hackers often rely on automated scripts to do their dirty work. These scripts can make numerous attempts to log into your WordPress administration page by trying thousands and millions of combinations of usernames and passwords. Not only can being bombed with login attempts slow down your web site for legitimate users, it may also succeed—giving hackers complete control of your site.

The defense: Of course, you should start with always using strong passwords. A longer, mixed-type password will take longer for a brute-force attack to decode. These attacks typically use combinations of dictionary words and numbers. (But remember that malware can render strong passwords useless.)

An even more effective defense is to install a login limiter for WordPress. A login limiter can essentially block or quarantine an IP address or username which tries and fails to send login requests above a threshold rate. For example, a login limit of 10 attempts per 5 minutes can be backed up with a penalty timeout of 1 hour.

A successful brute-force attack against a strong password effectively becomes impossible with these limits in place, because the hacker can never try enough variations (or rather, it would take many years of continuous attempts).

Two WordPress plugins which let you enforce a login limiter are Limit Login Attempts and the aforementioned Better WP Security.

These five strategies are the beginning of effective WordPress security—not the end. Like any form of security, defending WordPress is an ongoing process that must involve awareness of new threats combined with specific details about your own install environment.

Aaron Weiss is a technology writer and frequent contributor to eSecurity Planet and Wi-Fi Planet.