WordPress 中文文档

From WordPress Chinese

Security is an interesting topic, with a lot of shades of grey. WordPress developers take security very seriously, but as with any other system, there are potential security issues that may arise and there is always a tradeoff between security and convenience. We will go through some common things you can do to keep your WordPress installation secure.

What is security? Fundamentally, security is not about perfectly uncrackable systems, which might well be impossible to find and/or maintain. Security has more to do with trust and responsiveness. For example, a trusted host runs a stable, patched branch of their webserver (be it Apache, IIS, or whatever). They should tell you this, test their configuration themselves, and let you determine it for yourself. An untrusted host does not apply patches when they are released and does not tell you what server versions they are running.

Several themes run through this guide:

1. Limiting access: Making smart choices that effectively lower the possible entry points available to a malicious person.
2. Containment: If a weak point in your installation is found by a malicious person, your system should be configured to minimize the amount of damage that can be done once inside your system.
3. Knowledge: Keeping backups, knowing the state of your WordPress installation at regular time intervals, documenting your modifications all help you understand your WordPress installation.

Vulnerabilities on your computer

Make sure the computers you use to post to WordPress are free of spyware, malware, adware, and virus infections; and are running secure, stable versions of your applications. For example, none of the following makes the slightest difference if there is a keylogger on your PC.

Vulnerabilities in the WordPress package itself

WordPress could have vulnerabilies as a result of how the program is written that allow an attacker to pass HTTP arguments, bad URI strings, form input, etc, that could cause Bad Things to happen.

There are two ways to deal with this problem:

1. Keep up to date with the latest WP version: The WordPress developers do not maintain security patches for older WordPress versions. Once a new version has been released or the vulnerability has been fixed then the information required to exploit the vulnerability is almost certainly in the public domain making any old versions more open to attack by a simple script kiddie.
2. Report bugs: If you find what you think is a bug, report it -- See Submitting_Bugs. You might have uncovered a vulnerability, or a bug that could lead to one. If you think you have found a serious security flaw email security@wordpress.org with the information first.

Server vulnerabilities

The webserver running WordPress, the database with the WordPress data, PHP and any other scripting/programming language used for plugins or helper apps could have vulnerabilities. Therefore, make sure you are running secure, stable versions of your web server, database, scripting interpreter, or make sure you are using a trusted host that takes care of these things for you.

It should also be mentioned that if you're on a shared server (one that hosts other people besides yourself) if someone else is compromised, then it's very likely you could be compromised too even if you follow everything in this guide. Be sure to ask your web host what security precautions they take.

Network vulnerabilities

The network on both ends -- the WordPress server side and the client network side -- should be trusted. That means updating firewall rules on your home router and being careful about what networks you work from. A busy Internet cafe where you are sending passwords in cleartext over an unencrypted wireless connection is not a trusted network (The following article describing how to secure your email when using a wireless connection in a public place can be extended as a way of securely accessing you blog over ssh tunnels). Your host should be making sure that their network is not poisoned by hackers, and you should do the same. Network vulnerabilities allow passwords to be intercepted via sniffers and other sorts of havoc (such as man-in-the-middle attacks) to happen.

Passwords

Some vulnerabilities can be avoided by good security habits. An important element of this are passwords: do not use your own name for your password, do not use a dictionary word (from any language) for your password, do not use a 4 character string of numbers as your password. Your goal with your password is to make the search space as large as possible, so using numbers and varying capitalization all make it more difficult, statistically, to brute force a password. This is particularly important if you do not rename the administrator account. In that case half the puzzle is already solved for malicious users as they know what username will give them significant privileges to edit files and databases. The Automatic Password Generator can be helpful in generating reasonably complex passwords.

File permissions

Some of WordPress' cool features come from allowing some files to be writable by web server. However, letting an application have write access to your files is a dangerous thing, particularly in a public environment.

It is best, from a security perspective, to lock down your file permissions as much as possible and to loosen those restrictions on the occasions that you need to allow write access, or to create special folders with more lax restrictions for the purpose of doing things like uploading images.

Here is one possible permission scheme.

All files should be owned by your user account, and should be writable by you. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver.

• / -- the root Wordpress directory: all files should be writable only by your user account.
  • EXCEPT .htaccess if you want WordPress to automatically generate rewrite rules for you
• /wp-admin/ -- the WordPress administration area: all files should be writable only by your user account.
• /wp-includes/ -- the bulk of WordPress application logic: all files should be writable only by your user account.
• /wp-images/ -- image files used by WordPress: all files should be writable only by your user account.
• /wp-content/ -- variable user-supplied content: intended by Developers to be completely writable by all (owner/user, group, and public).
  • /wp-content/themes/ -- theme files. If you want to use the built-in theme editor, all files need to be group writable. If you do not want to use the built-in theme editor, all files can be writable only by your user account
  • /wp-content/plugins/ -- plugin files: all files should be writable only by your user account.
  • other directories under /wp-content/ should be documented by whatever plugin / theme requires them. Permissions may vary.

Database security

If you run multiple blogs on the same server, it is wise to consider keeping them in separate databases each managed by a different user. This is best accomplished when performing the initial WordPress installation. This is a containment strategy: if an intruder successfully cracks one of WordPress installation, this makes it that much harder to alter your other blogs.

If you administer MySQL yourself, ensure that you understand your MySQL configuration and that unneeded features (such as accepting remote TCP connections) are disabled. See Secure MySQL Database Design for a nice introduction.

Securing wp-admin

You can greatly enhance the security of your blog by adding additional access control to your /wp-admin/ folder using the AskApache Password Protection plugin. Adding server-side password protection to /wp-admin/ adds a 2nd layer of protection around your blog's admin area, login, and files. This forces an attacker or bot to attack this 2nd layer of protection instead of your actual admin files. Most of the time WordPress attacks are carried out autonomously by a malicious software bot.

The most common attacks against a WordPress blog usually fall into 2 categories.

1. Sending specially-crafted HTTP requests to your server with specific exploit payloads for specific vulnerabilites. These include old/outdated plugins and software.

1. Attempting to gain access to your blog by using "brute-force" password guessing.

By adding a 2nd layer of protection around these important files you force the attackers to have to break through that before they can even attempt to attack your main /wp-admin/. This protection uses Basic HTTP Authentication, the password is passed over the network uuencoded as plain text, not encrypted. The main benefit of this protection is in denying access to your servers files and alerting you to an attack against your blog before the attack reaches your /wp-admin/ doorstep.

The ultimate implementation of this "2nd layer" password protection is to require an HTTPS SSL encrypted connection for your /wp-admin/ directory, so that all communications and sensitive data is encrypted.

You can secure and encrypt all of your communication and important WordPress cookies using the Admin-SSL plugin. Works with Private and Shared SSL.

Plugins

Plugins that need write access

If a plugin wants write access to your WordPress files and directories, please read the code to make sure it is legit or check with someone you trust. Possible places to check are the Support Forums and IRC Channel.

Code execution plugins

As we said, part of the goal of hardening WordPress is containing the damage done if there is a successful attack. Plugins which allow arbitrary PHP or other code to execute from entries in a database effectively magnify the possibility of damage in the event of a successful attack.

A way to avoid using such a plugin is to use custom page templates that call the function. Part of the security this affords is active only when you disallow file editing within WordPress.

Security through obscurity

Security through obscurity is typically thought to be an unsound primary strategy. However, there are areas in WordPress where obscuring a bit could help with security:

1. Do not advertise the WordPress version you are running: If you are running an old WordPress version with known vulnerabilities, it is unwise to display this information to the public. Why not simply hide the WordPress version entirely? Even if you update packages as quickly as you can, there will be lag between the version release and your deployment, potentially enough time for a malicious person to carry out an attack. However, editing out all the places where WordPress advertises its version string in your theme can be a pain. It is still best to make sure you are running the latest WordPress version.
2. Rename the administrative account: You can do this in the MySQL command-line client with a command like update tableprefix_users set user_login='newuser' where user_login='admin';, or by using a MySQL frontend like phpMyAdmin.

Data backups

Backup your data regularly, including your MySQL databases (see Backing Up Your Database). Data integrity is critical for trusted backups. Encrypting the backup, keeping an independent record of MD5 hashes for each backup file, and/or placing backups on read-only media (such as CD-R) increases your confidence that your data has not been tampered with.

A sound backup strategy could include keeping a set of regularly-timed snapshots of your entire WordPress installation (including WordPress core files and your database) in a trusted location. Imagine a site that makes weekly snapshots. Such a strategy means that if a site is compromised on May 1st but the compromise is not detected until May 12th, the site owner will have pre-compromise backups that can help in rebuilding the site and possibly even post-compromise backups which will aid in determining how the site was compromised.