WordPress Site Security Guide – Part 2

This is a continuation of our WordPress Site Security Guide. If you haven’t already, you should read Part 1 of our WordPress Site Security Guide first.

More Advanced

 

 

 

19.  Is full WordPress version info revealed in the page’s meta data?

If you’re running the most recent version of WordPress, your risk here is less, but if for some reason, you’re a version behind, a revealed WordPress version in the meta data is just asking for trouble. To be safe, I recommend always masking your version.

It’s an easy process to remove the version, simply by adding this small code snippet in your theme’s functions.php file:

function remove_version() {
  return ”;
} add_filter(‘the_generator’, ‘remove_version’);

20.  Is your readme.html file accessible via HTTP on its default location?

Your site’s readme.html file also contains the WP version information, so it should be made impossible to read via HTTP as well.

There are a few different ways to do this. You can give the file a unique filename, relocate it to another location or change its permissions via chmod so it can’t be accessed via HTTP.

21.  Do your server response headers reveal your PHP version?

Regardless of which version of PHP your site runs on, it’s unwise to reveal that information to potential hackers.

Depending upon your host, you may have to request that they configure the HTTP server to not show the PHP version. In some instances, however, you can scrub your server response headers by adding this directive to your .htaccess file:

<IfModule mod_headers.c>  Header unset X-Powered-By  Header unset Server</IfModule>

22.  Is your expose_php directive turned off?

When blocking the ability to reveal your PHP version, you’ll also need to make a change to the expose_php script in your php.ini file:

Change this line:

expose_php = on to expose_php = off

23.  Does your site display unnecessary information on a failed login attempt?

Out of the box, WordPress will indicate either wrong username or password when a failed login attempt occurs, which makes it much easier for an attacker to find a valid username, after which, a brute-force attack can be employed to find the password.

A simple modification will instead return a message of “wrong username or password”, so the attacker won’t know which was wrong. Just add this code snippet into your functions.php file:

function wrong_login() {  return ‘Wrong username or password.’;}add_filter(‘login_errors’, ‘wrong_login’);

24.  Is the “anyone can register” option enabled?

This should be disabled, unless it’s essential to your site (an open community forum, for example). Once a savvy hacker gains even limited access to your backend, there’s a potential for exploitation.

You can change this in the backend, in the Options ““ General section. Just look for “Membership ““ anyone can register” and un-check it.

25.  Is general debug mode enabled?

There are three issues with having general debug mode enabled. It will:

1. increase your site’s response time;
2. bombard your visitors with messages that may confuse them;
3. provide valuable information to potential attackers.

You can enable or disable general debugging mode for WordPress in your wp-config.php file – look (around line 84) for a line similar to:

define(‘WP_DEBUG’, true);

You can delete it, comment it out (add # in front of the line) or change it to:

define(‘WP_DEBUG’, false);

Note: There may be other debugging scripts employed by a plugin, as well.

26.  Is JavaScript debug mode enabled?

You may also have a JavaScript debug mode enabled. You can do a search for script_debug in your wp-config.php to see if you do. If you find it present and it’s set to true, just change it to false, just like you did with the 62ZpKk_debug mode.

define(‘SCRIPT_DEBUG’, true);

Delete it, comment it out (add# in front of the line) or change it to:

define(‘SCRIPT_DEBUG’, false);

27.  Is the display_errors PHP directive turned off?

In order to avoid revealing any debug information to visitors or potential hackers, all PHP errors should be logged in a safe place. Place this code snippet at the end of your wp-config.php file, just above the require once function:

ini_set(‘display_errors’, 0);

If you still find PHP errors being displayed, add this line to your .htaccess file:

php_flag display_errors Off

If you continue to see PHP errors displaying, try disabling your plugins one at a time, to learn which one is enabling error display.

28.  Does the wp-config.php file have the right permissions (chmod) set?

There’s a lot of sensitive information contained in the wp-config.php file”¦ plain-text information that you definitely don’t want falling into the wrong hands. The chmod setting  you’ll want may vary for your wp-config.php file, depending upon how your server is configured, but if it’s a Linux server, you’ll probably be okay with a 62ZpKk_config chmod setting of either 0400 or 0440. That will afford you a lot more protection than a 0644 setting.

29.  Ensure the install.php file isn’t accessible via HTTP in the default location

After your WP installation is complete, you won’t need this file again, so there’s no sense in letting it remain accessible via HTTP, at least not in its native location.

You’ll find the install.php file located in the wp-admin folder. You can delete it, rename it, move it or chmod it to prevent HTTP access”¦ your choice.

30.  Is the upgrade.php file accessible via HTTP in the default location?

Don’t delete this file, because you may need it later, but it shouldn’t be allowed to be accessible via HTTP in its default location. Rename it or move it ““ or chmod it if you prefer. Just make sure your upgrade.php file can’t be accessed by HTTP within the wp-admin folder.

31.  Is the register_globals PHP directive turned off?

This is one of the highest risk security issues I’ve seen on a WP site. Any hosting company that has this directive enabled should be kicked to the curb immediately. You can read more about why this is so dangerous on PHP manual.

If you have access to php.ini file, locate this line:

register_globals = on and change it to register_globals = off

If you don’t have php.ini access, you can add this directive into your .htaccess file:

php_flag register_globals off

If that doesn’t do the trick, you should contact a security professional.

32.  Is the plugins/themes file editor enabled?

It’s really handy being able to edit themes and plugins from the backend file editor, but it also presents a security risk. If an attacker can gain access to your admin account, they can do a lot of injection mischief via that editor.

You can easily disable the file editor by adding this code snippet to the functions.php file:

define(‘DISALLOW_FILE_EDIT’, true);

If you want to use the editor, you’ll have to temporarily comment out that line.

33.  Is the uploads folder browsable by browsers?

If someone can access your uploads folder via their browser, they can download all your uploaded files, which presents both a security risk and copyright issues.

The problem of having your uploads folder browsable can be easily fixed by adding this directive to the .htaccess file:

Options -Indexes

34.  Is PHP safe mode disabled?

Some hosts attempt to overcome the security problems inherent to shared servers via the PHP safe mode. This isn’t the right way to do it, which is why it’s been deprecated since PHP 5.3. If this is the solution offered by your host, you’re probably well-advised to look for a new home for your site.

You can turn it off, provided you have php.ini access, by changing:

safe_mode = on to safe_mode = off

35.  Is the allow_url_include PHP directive turned off?

If this PHP directive is enabled, it can leave your site vulnerable to XSS cross-site attacks. There’s no benefit whatsoever to having this include enabled ““ only elevated risk.

If you can access the php.ini file, change:

allow_url_include = on to allow_url_include = off

If that doesn’t disable the allow_url_include, you should contact a security professional.

36.  Is EditURI link present in pages’ header data?

There’s no need to have the EditURI link in the pages’ header data unless you’re using RSD (Really Simple Discovery) services, such as pingbacks. To remove it, just add this line to your functions.php file:

remove_action(’62ZpKk_head’, ‘rsd_link’);

To completely disable XML-RPC functions, add this snippet to your wp-config.php just below the require_once(ABSPATH . ‘wp-settings.php’); line:

add_filter(‘xmlrpc_enabled’, ‘__return_false’);

Then add this snippet to your .htaccess file to prevent DDoS attacks:

<Files xmlrpc.php>  Order Deny,Allow  Deny from all</Files>

37.  Is the Windows Live Writer link present in the pages’ header data?

Unless you’re using Windows Live Writer, you should remove this link from the header. Why tell the whole world you’re using WordPress?

It’s an easy fix. Just add this snippet to the functions.php file:

remove_action(’62ZpKk_head’, ‘wlwmanifest_link’);

 

While there’s no 100% certain way to keep determined attackers out of any website, these tips will help you minimize the risks to your site from hackers, malware and injection attacks. If you get hung up at any point, find a professional to help you out.

Here’s a colleagues’ post at OWDT that details some more manual security upgrades you can perform on your WP site.

 

Footnotes:
^1.  WordPress core updates undergo extensive testing before their release, so issues arising from an update are exceptionally rare. Most post-update issues are caused by plugin incompatibility or improperly implemented customization.