I opened up phpmyadmin, expecting to see a “categories” table. No dice. After a few minutes I figured it out – and I decided it might be a good idea to explain how the WordPress database is structured.

When I first opened the database, I was impressed with its size. It’s made up of only ten tables. The other CMS I’ve used (CMS Made Simple) uses dozens of tables – so this seemed pretty compact.

Part of how this is done is that things are compressed into the pre-existing tables, rather than given their own tables. As a result you’ve got a more compact, more efficient database structure – but not necessarily the most intuitive structure.

To the right, you’ll see an map of the basic database structure. In the middle is the most important table – wp_posts.

Post Information – wp_posts

This is the heart and sole of your WordPress blog. It contains the basic information about each post and this is how other information is linked to your posts.

There is a lot of information here, but the major fields are ID, post_content, and post_title. The ID is used to link your post to other fields (like comments), and the content and title fields make up the actual post.

That’s what is read and displayed for the user to read.

Comments – wp_comments

This table is connected to the wp_posts table, and it contains all of the comment and trackback information for your blog.

Each comment has a “comment_post_ID” field – which matches up with the individual ID of the post it is attached to. There are a number of other fields that contain the comment data – like comment_author, comment_author_url, and comment_content.

Category and Tag Information – wp_terms

The original question was, “Where is the category information stored?”

This used to be in a “category” field in the wp_posts table. However, a more efficient way to do this was to create a new table with all the category information and a third table to link a post with a category – since each post can have multiple categories.

Each category and tag is defined in the wp_terms field. This includes the name, an id, and a description. In the wp_terms_taxonomy field, each “term” is defined as either a tag or a category.

Then, the wp_terms_relationships includes two numbers – a term id and a post id. By grabbing every term that uses a post’s id, WordPress can immediately identify all of the appropriate categories and tags to use.

For performance sake (but not necessarily readability), the tags and categories have been made synonymous in the database. They’re all “terms” – which cuts down on the number of queries WordPress needs to make to build a page.

Non-sequitors – wp_links, wp_users, and wp_options

The last few tables are non-sequitors. They aren’t attached to the wp_posts table, and they define random things about your blog.

For example, wp_links contains the information about links that are displayed in your “Links” section… if you use it.

The wp_users table identifies the user accounts that are registered for your blog. Chances are that that includes you – and no one else. The wp_usermeta table is attached to this, and it includes some options for each user (like whether or not they use the WYSIWYG editor for writing posts).

The only really important table here is wp_options.

This defines all of the major options of your blog – like the url, the title, the description, etc. Anything you set in the Dashboard is stored in a row in this table.

This also stores all of the plugin and widget information. WordPress uses a nifty trick to store widgets – it simply serializes them and stores them in a textfield in the database. Then, it can put the widget back together with by deserializing it.

This way a widget can be stored and reconstructed from one database row in one table, rather than creating a whole new table for each widget. It makes the information in the database pretty unintelligible – but it cuts down massively on the number of queries needed to create and use the widgets.

Start Messing Around

The purpose of this, of course, is to understand the database structure so that you can mess around with it yourself. That is, after all, the point of open source programs.

So lurk around in the database a bit. This is very useful information for writing plug-ins that need to interact with the WordPress database.

There are a bunch of ways you could create and check passwords – from an insecure string in a database to an encrypted “hash” that you check against user input. This tutorial will show you how to use the crypt() function to store and check passwords in a php script.

What Does the Crypt() Function Do?

The crypt() function takes two parameters – the first parameter is the actual input (the password to test) and the second parameter is a “salt” or encryption key that is used to encrypt the password phrase.

Let’s take a look at what the crypt() function does with some input.

echo crypt("Gobble", "xt");

Would yield the output…

xt0iPj3UKFQSM

The function used the encryption key “xt” to turn “Gobble” into an encrypted mess. Now, a person looking through the database won’t be able to find out a person’s password. They’ll only find the encrypted password – which won’t work if you enter it into a script.

The Crypt() Function Stores the Encryption Key in the Output

There’s an important pattern here, though, that we can see if we look at a couple of crypt() calls in a row.

echo crypt("Gobble", "ab");
echo crypt("Gobble", "td");
echo crypt("Gobble", "pz");

Would yield the output…

ab30/okS7bRdo
tdylLlJ9zwOss
pz0u5z5fgyCK.

You can break each piece of output into two pieces – the first two characters and the last 11 characters.

The first two characters “ab,” “td,” and “pz” are the three “salts” or encryption keys that we used in our crypt() calls. The last 11 characters are the actual encrypted pass phrases.

This simple point is crucial to the functioning of crypt(). It stores the encryption key inside the encrypted phrase, so that you can use it to encrypt a new phrase – and compare them. If you use the encrypted phrase as your “salt” (the second parameter for crypt()), the function will isolate the encryption key and ignore the rest.

So this example would output “Passwords match!”

$password = "Gobble"; // User input
$salt = "ab"; // Encryption key
$encrypted = crypt($password, $salt);
if ( crypt($password, $encrypted) == 
    $encrypted) {
  echo "Passwords match!"; }

In this case we’re using the encrypted password ($encypt) to perform the encryption algorithm on the user’s input ($password) to see if they match. Normally, you would have $encrypted stored in the database to perform comparisons in your script.

Use an MD5 Hash Salt to Encrypt Phrases Over 8 Characters

The final thing to keep in mind about crypt() is that it can use different kinds of salts or encryption keys. The two-character salt we’ve been using is pretty weak. It also has a flaw in functionality – using a two-character encryption key, the crypt() function will ignore everything past the first 8 characters of the phrase to be encrypted.

So both of these statements would have the same output.

echo crypt("Gobbledeygook", "ab");
echo crypt("Gobbledeygah", "ab");

The crypt() function is only encrypting the first eight characters – “Gobblede”. The rest is ignored.

You can change this by using a special type of encryption key – a md5 hash. Under normal circumstances, this is enabled in php, but you can double check by seeing if the constant CRYPT_MD5 is set to ’1′.

An md5 hash salt is formatted like this – $1$xxxxxxxx$. “$1$”, followed by eight random characters, followed by a closing “$”. You could create one yourself to use as a salt.

However, in most cases if you provide no salt or encryption key at all, php will generate a random salt for you. So, for example, when you are entering a new password into the database you can use this statement…

$password = crypt("Gobble");

This variable ($password) can now be stored in the database. Remember that $password holds both the encrypted phrase (Gobble) and the random encryption key. So to check if a user entered the correct password you would fetch $password from the database and use this statement…

if ( crypt($userInput, $password) == $password)
{ //  Ok, the passwords matched }

Now that you know how crypt() works, get to it. Start creating user-authentication scripts and work your encryption magic.

The original post has some header information about this particular hack (a modified c100 shell), as well as a link to some search results about the file. I looked through the source code for the shell script and tested it out on my local server – getting some link-filled files is the least that this script could do.

Once the script is loaded on your server, anyone can access it remotely and have full access to your system.

The script allows you to navigate through the server’s directories like any remote file-manager. I noticed that it could even go up out of the web server root and into my local folders as well.

The script gathers up all the details on your computer – like operating system build, running processes, ip address, etc. The user can run shell commands, create files, upload files, and do other kinds of nasty things.

It would be pretty easy for someone to use this to find the mysql username/password, hack your database, do whatever they want, and pretty wreck your entire site. Or worse, they could use this to do some nasty things to the server itself – potentially wrecking other peoples’ sites.

So how do you protect against this? Well, I’m not sure what you would do to protect against the shell script once it’s loaded up. It looks like it’s built to bypass most security precautions and give the hacker access to whatever he or she wants.

Your best bet is to be vigilant in restricting front-end uploads to your site. If you’ve got an upload script, be sure you restrict what file extensions can be uploaded.

This script needs to be named with a file extension that is read as php – so you should never allow users to upload php files (or html if you set up your server to execute those as php).

Being more restrictive is better than less restrictive – so ban all file extensions except the ones you know are safe. So, for example, you might allow “.jpg, .gif, .png” for pictures, and “.doc, .odt, .pdf, .txt, .rtf” for documents.

If you’ve got any other suggestions for security against this sort of thing, please comment away. Otherwise, take a look at the script so that you are aware of what it can do.