Here are some relatively simple steps that should help ‘toughen up’ your WordPress installation:

Don’t use the “admin” account.

Either change the username via MySQL

UPDATE wp_users SET user_login = 'username' WHERE user_login = 'admin'

*where “username” is whatever you want to call it.

Or, create a new/unique account with administrator privileges and delete the original admin account.

From WordPress 3.0 you can set the administrator username and password during the installation process, which is a good step forward.

Use secure passwords.

Use strong passwords to protect your website from dictionary attacks. WordPress will tell you when your password is strong (the admin interface for users has a password strength indicator).

Don’t restrict your strong passwords to the WordPress installation, do the same for FTP, SSH and MySQL as well.

Update the folder permissions on your WordPress files.

A good rule of thumb is to set the following permissions:

Files should be set to 644
Folders should be set to 755

If these settings are too restrictive, i.e. you can’t upload files, change the permissions to increase the privileges (e.g. 775 or even 777).

Remember, permission levels vary depending on your specific server configuration, but you can generally set them to the desired level quite easily via FTP or SSH clients.

For example, with SSH:

find [your path] -type f -exec chmod 644 {} \;
find [your path] -type d -exec chmod 755 {} \;

Move the configuration file (wp-config.php).

From WordPress 2.6 it became possible to move the configuration file up a directory and out of the WordPress root folder.

For example, if WordPress is located in the following directory:

public_html/wordpress/wp-config.php

You can move it to the following directory:

public_html/wp-config.php

WordPress automatically checks the parent directory if the configuration file is not found in your website’s root directory.

This makes it nearly impossible for anyone to access your configuration file as it now resides outside the website’s root directory.

Move the wp-content directory.

Like the configuration file, WordPress 2.6 added the ability to move the wp-content directory to another location.

Once moved, make two additions to the configuration file to identify the new location:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content');
define('WP_CONTENT_URL','http://domain.com/blog/wp-content');

You may also need to define the new location for plugins:

define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins');
define('WP_PLUGIN_URL','http://domain.com/blog/wp-content/plugins');

If hackers can’t find your wp-content folder’s location, clearly it becomes far more difficult for them to hack it.

Stay current with all updates.

The main WordPress installation files, plugins and themes can be updated easily via the admin interface. Make sure you do so each time a new version of either are released.

For plugins, the plugin change log makes it easy to see what has changed and therefore ensure compatibility with your version of WordPress.

Remove the WordPress version information from your header.

Viewing source on most WordPress websites will reveal what version of WordPress the website is running.

<meta name="generator" content="WordPress 3.0.1" /><!-- leave this for stats -->

This helps hackers find vulnerable blogs or determine ways to hack a particular version.

To remove, find the code shown below in your header.php file and delete it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /><!-- leave this for stats -->

The wp_head function also includes the WordPress version in your header. To remove, include the following line of code in your theme’s functions.php file:

remove_action('wp_head','wp_generator');

Use secret keys.

A secret key is a hashing salt, which makes your website harder to hack by adding random elements to the password. These secret keys are found in the WordPress configuration (wp-config.php) file.

Visit the following URL to get the secret keys: https://api.wordpress.org/secret-key/1.1/salt/

Replace the following in the configuration file

define('AUTH_KEY','put your unique phrase here');
define('SECURE_AUTH_KEY','put your unique phrase here');
define('LOGGED_IN_KEY','put your unique phrase here');
define('NONCE_KEY','put your unique phrase here');
define('AUTH_SALT','put your unique phrase here');
define('SECURE_AUTH_SALT','put your unique phrase here');
define('LOGGED_IN_SALT','put your unique phrase here');
define('NONCE_SALT','put your unique phrase here');

With the generated keys (example only):

define('AUTH_KEY','*QCT0a,T+3hxeg)ti7k}#~<AQSmm&x+ff=*$d:)<-;+!a?yS{ArmuR-#*GyLCgI)');
define('SECURE_AUTH_KEY','[)|y._i~B5js,h3@4%M[<l:DJ&]Ou$2|n(e?DJ`+R4pk6um/6zS%6@@i{^N-6(4]');
define('LOGGED_IN_KEY','@+l2X{3wvy/1K[zRm|P_r;WixJ:,>V&JL![gyJq ?b[Wf.W|U_MKutdrL*$l][-S');
define('NONCE_KEY','T$R>#*2)2kO?NIr&o|>[L>T5%YGd^yJ+eE$7wkcL-?1v]-X*{f`Pg)NZqKU}^e8R');
define('AUTH_SALT','<8JD%+O!t.F%]6RaO9L_MI<w2Lw_-Bc5u_(WDdPoO0D;j9zwu*?1i{%nH/RBjF6J');
define('SECURE_AUTH_SALT','oS|EP&Pm`bf8iG!C<X8#yFG%8J)x G+3M`wRBtp#]7)&hj}ZV/p> yh-BtbBRbTk');
define('LOGGED_IN_SALT','tW4|J/m|habEJ+BTvF0PfpuiOgf-6,dIav-5K|FTM$&Agy;FqDjp|5Ci7>nJFD/#');
define('NONCE_SALT','T-v&f++w!c%5zs2t8qH?,n,/WE&uWd--o4t{FL49/4e~|e+HV+.~A?JYZ1Ev<5)u');

You can add or amend the secret keys at anytime. This will invalidate all existing cookies and require users to login again.

Change the WordPress table prefix.

You can define the WordPress database table prefix in the WordPress configuration file. By default, the prefix is set to:

$table_prefix = 'wp_';

Change this to whatever you prefer.

If you already have a version of WordPress installed, you will need to manually amend the database table names in MySQL, or do a clean install and data import.

Force SSL on login and admin access.

Set the following option in the WordPress configuration file to force SSL (HTTPS) on the login and admin screens.

define('FORCE_SSL_LOGIN',true);
define('FORCE_SSL_ADMIN',true);

Use IP lockdown on the wp-admin directory.

Create an .htaccess file in your wp-admin directory with the following lines of code:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny, allow
deny from all
#IP whitelist
allow from 72.14.207.99
allow from 216.239.51.99

Where the IP address lines are whatever your chosen IP addresses are. Only users with these IP addresses will have access to the wp-admin folder and hence the admin part of the blog.

Resources:

• http://codex.wordpress.org/Hardening_WordPress
• http://codex.wordpress.org/Changing_File_Permissions
• http://codex.wordpress.org/Editing_wp-config.php
• http://codex.wordpress.org/htaccess_for_subdirectories

If you have any more suggestions, that don’t necessitate plugins, feel free to comment.

The PCI SSC (Council) is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. Non-compliant companies who maintain a relationship with one or more of the card brands, either directly or through an acquirer risk losing their ability to process credit card payments and being audited and/or fined.

All in-scope companies must validate their compliance annually. This validation can be conducted by Qualified Security Assessors, i.e. companies that have completed a three-step certification process by the PCI SSC which recognises them as being qualified to assess compliance to the PCI DSS standard. However, smaller companies have the option to use a Self-Assessment Questionnaire. Whether this questionnaire needs to be validated by a QSA depends on the requirements of the card brands in that merchant’s region.

The current version of the standard specifies 12 requirements for compliance, organised into 6 logically related groups, which are called “control objectives.”

1. Build and Maintain a Secure Network
   • Requirement 1: Install and maintain a firewall configuration to protect cardholder data
   • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2. Protect Cardholder Data
   • Requirement 3: Protect stored cardholder data
   • Requirement 4: Encrypt transmission of cardholder data across open, public networks
3. Maintain a Vulnerability Management Program
   • Requirement 5: Use and regularly update anti-virus software
   • Requirement 6: Develop and maintain secure systems and applications
4. Implement Strong Access Control Measures
   • Requirement 7: Restrict access to cardholder data by business need-to-know
   • Requirement 8: Assign a unique ID to each person with computer access
   • Requirement 9: Restrict physical access to cardholder data
5. Regularly Monitor and Test Networks
   • Requirement 10: Track and monitor all access to network resources and cardholder data
   • Requirement 11: Regularly test security systems and processes
6. Maintain an Information Security Policy
   • Requirement 12: Maintain a policy that addresses information security

Compliance with these requirements can be summarized into 3 main stages:

• Collecting and storing: Secure collection and tamper-proof storage of all log data so that it is available for analysis.
• Reporting: Being able to prove compliance on the spot if audited and present evidence that controls are in place for protecting data.
• Monitoring and alerting: Have systems in place such as auto-alerting, to help administrators constantly monitor access and usage of data. Administrators are warned of problems immediately and can rapidly address them. These systems should also extend to the log data itself –- there must be proof that log data is being collected and stored.

What does this actually mean for web application developers?

It is considerably more expensive and more time-consuming to recover from a security incident than to take preventative measures ahead of time. If you follow the guidelines below, you will go along way to securing you application in line with the PCI DSS regulations. Many of the measures apply to general application security, but since PCI DSS is all about security, they are worth mentioning.

Server-level Security:

• Separate web- and database-servers on to different physical machines.
• Secure the web- and database-servers with traditional techniques. Only authorised accounts should have the capabilities to run tasks on the machine. That means not giving admin-rights to the user account.
• Keep servers up-to-date with the latest patches and software releases.
• Minimise the number of services running on the server. This means limiting the services to only those required for the web- or database-servers to function.
• Secure information in transit between servers. This may mean physically securing the network to prevent evesdropping via encryption or obfuscating the data amongst innocuous ‘noise’.
• Secure the database server behind a firewall.

Application-level Security:

• Separate ColdFusion, the webserver and database server user accounts. They should never be under the same system account.
• Create a database user specifically for your ColdFusion datasource and restrict it to only the activities required for the application. The user should not have database-owner rights, access to databases not relating to the application or access to the system tables.
• Revoke privileges in the ColdFusion datasource definition to prevent the SQL commands CREATE, DROP, GRANT, REVOKE and ALTER.
• General settings in the ColdFusion Administrator:
  • Check the Disable access to internal ColdFusion Java components option.
  • Check the Enable Global Script Protection option.
  • Add a Missing Template Handler.
  • Add a Site-wide Error Handler.
  • Reduce the Maximum size of post data from 100MB.
  • Enable Timeout Requests, and set to 60 seconds or less.
  • Disable Robust Exception Handling on production servers.

Web Application-level Security:

• Use secure HTTP to transfer data and/or when logged into ‘administration’ secutions of your web application.
• Timeout sessions after 15 minutes and on browser close.
• Provide multi-level login processes. For example, lock the application after 3 failed attempts for a period of 10 minutes.
• Do not identify whether the username or password are incorrect, simply notify the user that their login failed and that they must try again.
• Encrypt passwords stored in the database with a standard such as SHA-256 or ‘stronger’.
• Use CAPTCHAs (textual and aural) to prevent automated robots hacking into your application.
• Run regular penetration tests on your application to identify potential problems.
• Encrypt credit card information held in the database or other storage mechanism. Only store credit card data in line with the PCI DSS regulations.

Code-level Security:

• Application.cfc – Set the scriptProtect Application variable to true to enable application-wide cross-site script protection.
• CFQueryParam – This tag, importantly, verifies the data type of a query parameter and, for RDBMSs that support bind variables, enables ColdFusion to use bind variables in the SQL statement. Bind variable usage enhances performance when executing a cfquery statement multiple times. There are limitations to the use of the cfqueryparam tag. In ColdFusion 7 for example, you cannot use them in queries using the cachedWithin attribute. Similarly, they cannot be used in ORDER BY clauses, although the use of conditional logic should resolve the need for order by variables.
• Functions – As a rule of thumb, validate all the data being passed into a query prior to it being used. ColdFusion MX 7 saw the introduction of the isValid() function. This function tests whether a value meets a validation or data type rule and can be used to replace a large number of type-specific functions such as isArray(), isBinary(), isBoolean(), isDate(), isNumeric() and isSimpleValue() etc.
• Stored Procedures – I often favour the use of stored procedures over standard queries. Not only do they add an additional level of performance, they provide an additional level of security; ColdFusion does not do any raw processing of queries in the web code, it simply passes variables down the wire to the database server.

Conclusion

The goal of the PCI Data Security Standard is to protect cardholder data that is processed, stored or transmitted by merchants. The security controls and processes required by PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account number printed on the front of a payment card. Merchants and any other service providers involved with payment card processing must never store sensitive authentication data after authorisation. This includes sensitive data that is printed on a card, or stored on a card’s magnetic stripe or chip – and personal identification numbers entered by the cardholder.

By following the points made above, you will go a long way to meeting the PCI DSS guidelines, whilst also securing your infrastructure and applications in a more general sense.

Caveat: The views and comments written in this article are provided as a guideline. I hold no responsibility for the security of your applications and data based upon the information provided.

Why should you be worried about security?

The Web is changing many of the assumptions that people have historically made about computer security and publishing. As the Internet makes it possible for web servers to publish information to millions of users, it also makes it possible for computer hackers, crackers, criminals, vandals, and other “bad guys” to break into the very computers on which the web servers are running. Once subverted, web servers can be used by attackers as a launching point for conducting further attacks against users and organisations.

It is considerably more expensive and more time-consuming to recover from a security incident than to take preventative measures ahead of time.

This blog post started on the premise of protecting your website from a SQL Injection Attack. However, it is also appropriate to discuss, at a relatively high level, how to secure your server architecture and applications.

Server-Level Security

• Separate web- and database-servers on to different physical machines.
• Secure the web- and database-servers with traditional techniques. Only authorised accounts should have the capabilities to run tasks on the machine. That means not giving admin-rights to the user account.
• Keep servers up-to-date with the latest patches and software releases.
• Minimise the number of services running on the server. This means limiting the services to only those required for the web- or database-servers to function.
• Secure information in transit between servers. This may mean physically securing the network to prevent evesdropping via encryption or obfuscating the data amongst innocuous ‘noise’.
• Secure the database server behind a firewall.

Application-Level Security

• Separate ColdFusion, the webserver and database server user accounts. They should never be under the same system account.
• Create a database user specifically for your ColdFusion datasource and restrict it to only the activities required for the application. The user should not have database-owner rights, access to databases not relating to the application or access to the system tables.
• Revoke privileges in the ColdFusion datasource definition to prevent the SQL commands CREATE, DROP, GRANT, REVOKE and ALTER.
• General settings in the ColdFusion Administrator:
  • Check the Disable access to internal ColdFusion Java components option.
  • Check the Enable Global Script Protection option.
  • Add a Missing Template Handler.
  • Add a Site-wide Error Handler.
  • Reduce the Maximum size of post data from 100MB.
  • Enable Timeout Requests, and set to 60 seconds or less.
  • Disable Robust Exception Handling on production servers.

Code-Level Security

• Application.cfc – Set the scriptProtect Application variable to true to enable application-wide cross-site script protection.
• CFQueryParam – This tag, importantly, verifies the data type of a query parameter and, for RDBMSs that support bind variables, enables ColdFusion to use bind variables in the SQL statement. Bind variable usage enhances performance when executing a cfquery statement multiple times.

  <cfquery name="qry" datasource="#APPLICATION.dsn#">
  SELECT column1, column2, column3
  FROM tableName
  WHERE column4 = <cfqueryparam value="#variable1#" cfsqltype="cf_sql_bit" />
  AND column5 LIKE <cfqueryparam value="%#variable2#%" cfsqltype="cf_sql_varchar" maxlength="200" />
  AND column6 IN (<cfqueryparam value="#variable3#" cfsqltype="cf_sql_integer" list="true" />)
  </cfquery>

  There are limitations to the use of the cfqueryparam tag. In ColdFusion 7 for example, you cannot use them in queries using the cachedWithin attribute. Similarly, they cannot be used in ORDER BY clauses, although the use of conditional logic should resolve the need for order by variables.

• Functions – As a rule of thumb, validate all the data being passed into a query prior to it being used. ColdFusion MX 7 saw the introduction of the isValid() function. This function tests whether a value meets a validation or data type rule and can be used to replace a large number of type-specific functions such as isArray(), isBinary(), isBoolean(), isDate(), isNumeric() and isSimpleValue() etc.
• Stored Procedures – I often favour the use of stored procedures over standard queries. Not only do they add an additional level of performance, they provide an additional level of security; ColdFusion does not do any raw processing of queries in the web code, it simply passes variables down the wire to the database server.

Additional Resources

• Web Security, Privacy and Commerce
• O’Reilly’s The Web Application Hacker’s Handbook
• Adobe’s whitepaper – ColdFusion 8 Developer Security Guidlines (PDF, 281k)
• Adobe’s whitepaper – ColdFusion 7 Developer Security Guidlines (PDF, 217k)
• Adobe DevNet – Learning Stored Procedure Basics in ColdFusion 8
• 0×000000 # The Hacker Webzine’s article on Attacking ColdFusion
• Three part series from Mark Kruger (ColdFusion Muse) – Part 1, Part 2, Part 3
• Brad Wood’s article on CFQueryParam is not just for security.