Since the release of Wordpress 2.0, a pesky bug has been annoying several bloggers. The nice AJAX effects in the administrator panel stopped working; even a fully privileged user would receive a “You don’t have permission to do that” message when trying to add or remove categories, posts and more.

The Wordpress developers are aware of this bug, but the ticket has recently been moved to milestone 2.4. Which basically means we bloggers will have to wait another few months for an official fix.

So far, it has been unclear as to what is causing this problem. I recently upgraded to Wordpress version 2.2 (many important bugs have been fixed, I recommend it) but I was disappointed to find out that the AJAX problem was still there. That’s when I decided to check the root of this bug myself.

Suhosin

Suhosin is a patch for PHP that hardens it against a wide range of web attacks. It’s got a truly amazing set of precautions for problems of which you didn’t even know they existed.

One of its features is cookie encryption. This basically encrypts the cookie using both server and client specific information (a custom key, user agent and more) before sending it to the client. This feature is useful, because if some malicious code on the client-side (XSS is most common) manages to get a hold of the cookie it can not do anything with it.

In addition to encrypting the cookie before sending it to the client, Suhosin will also decrypt cookies it receives so you can use it in PHP without problems.

Or can we…?

All of the AJAX-powered actions performed in the Wordpress admin panel go to one script: /wp-admin/admin-ajax.php
The first thing this script does is calling the function check_ajax_referer() (located in /wp-includes/pluggable.php).
This is what the function looks like:

function check_ajax_referer() {
	$cookie = explode('; ', urldecode(empty($_POST['cookie']) ? $_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must pass cookie=document.cookie
	foreach ( $cookie as $tasty ) {
		if ( false !== strpos($tasty, USER_COOKIE) )
			$user = substr(strstr($tasty, '='), 1);
		if ( false !== strpos($tasty, PASS_COOKIE) )
			$pass = substr(strstr($tasty, '='), 1);
	}
	if ( !sp_login( $user, $pass, true ) )
		die('-1');
	do_action('check_ajax_referer');
}

As you can see, Wordpress avoids using the HTTP Cookie header for AJAX requests (it’s even mentioned in the comment). Instead, the cookie is appended to the request data.This is done, of course, on the client side using Javascript.

When document.cookie is appended to the request, there is still no problem. The Cookie header and the document.cookie are practically the same. But once the request arrives at the server, Suhosin will only decrypt the Cookie. Not the appended document.cookie, because it is not recognised as a cookie at all (it’s just an encoded variable).

So when Wordpress reads the cookie from the request data, it actually reads the encrypted cookie. And you can’t log in with an encrypted cookie, so you are denied permission.

There is a workaround

Fortunately, most browsers (as far as I know) also send the Cookie header. Suhosin flawlessly decrypts the data contained in this header and puts everything in the $_COOKIE variable.

I am not really sure why the Wordpress developers chose to send cookies via the request body, but until they come up with a better fix for this problem, I am providing the following workaround:

function check_ajax_referer() {
	// Suhosin workaround
	$dough = ini_get('suhosin.cookie.encrypt');
	if ( 1 == $dough || 'On' == $dough || 'on' == $dough ) {
		$user = $_COOKIE[USER_COOKIE];
		$pass = $_COOKIE[PASS_COOKIE];
	} else {
		$cookie = explode('; ', urldecode(empty($_POST['cookie']) ? $_GET['cookie'] : $_POST['cookie'])); // AJAX scripts must pass cookie=document.cookie
		foreach ( $cookie as $tasty ) {
			if ( false !== strpos($tasty, USER_COOKIE) )
				$user = substr(strstr($tasty, '='), 1);
			if ( false !== strpos($tasty, PASS_COOKIE) )
				$pass = substr(strstr($tasty, '='), 1);
		}
	}
	if ( !sp_login( $user, $pass, true ) )
		die('-1');
	do_action('check_ajax_referer');
}

This can be applied to any Wordpress installation. Servers without Suhosin will run Wordpress the regular way. Servers with Suhosin cookie encryption enabled will make Wordpress fall back to using the standard cookie.

I might look into writing a PHP function that simulates Suhosin cookie decryption. This will allow Wordpress to use the cookie in the request in both cases. Unfortunately, I was unable to find sufficient information for this.

Patch for Wordpress 2.2

I created a patch file for Wordpress 2.2. It must be applied to /wp-includes/pluggable.php.

Download the file.
Linux users can patch using:
$ patch /path/to/wp-includes/pluggable.php /path/to/pluggable.diff
Windows users can download GNU patch for Windows. And run it from the Command line interface:

C:\path\to\patch.exe \path\to\wp-includes\pluggable.php \path\to\pluggable.diff

You might think the browser is the weak link here, because it doesn’t handle the cookie correctly. That is true, but apparently it is difficult to flawlessly apply the same origin policy. I might be wrong though, but it doesn’t really matter for now, because this article focuses on something else.

The server side application at site A could have been protected against the attack. In this article, I will highlight a few methods that could make the process safer. Airtight sessions.

As developers of website applications, we will have to avoid relying on cookie data contained in the HTTP Cookie header when performing certain actions. These certain actions are basically the ones that require authentication (e.g.. changing user preferences, making a blog post, digging a story, etc.)
There are two ways in which this can occur: 1) using an HTML form (with POST data) and 2) using the XMLHttpRequest object. The difference is that the latter uses JavaScript and the first does not (or does not have to, at least).
We’ll have a look at the HTML form scenario first.

The HTML form way

The following form allows an authenticated user to change his or her email address (just try to imagine it, if you don’t agree).
It is generated by a PHP script (doesn’t matter for now, but will be useful later),

The relevant part of the PHP script that takes care of this form (change_email.php) looks like this:

Note that the user is authenticated by means of the session variable logged_in. The session ID is, of course, obtained via a cookie.

We don’t want this, because the cookie might not be safe. Instead, we will use a custom solution. (There may be other possibilities to make this form safer, but I will demonstrate just one.)
To avoid using a cookie, we will make the session ID part of the form. The form code snippet will look like this:

When the form is submitted, it will also pass the session ID. Easy, right?

Now on to the change_email.php script. We must tell the session handler that we want to use the POSTed session ID instead of the one in the cookie (which is the default).
The relevant part is slightly rewritten:

Lines 2 through 6 make sure the POST request is handled using the session that was set in the form. Line 4 may seem kind of useless, but it prevents an E_NOTICE from being triggered (it’s become a habit of mine to code like this…)
The session_id() function allows us to change the session ID manually before starting the session.

This method should stop malicious JavaScript on external sites from abusing your cookies.

The XMLHttpRequest way

Imagine the previous situation of changing an email address, but then in AJAX style. I am not going into detail regarding the usage of the XMLHttpRequest object, because there are a bunch of frameworks that all work a bit differently.
Just keep the following points in mind:

• The request method is POST (the recommended method for this kind of stuff, by the way)
• The server side file is the same as the last version of change_email.php

So, basically, you will need to add the session ID cookie to the POST data. Luckily, you can use JavaScript to extract the ID from the existing cookies:

On line 14, PHPSESSID is the name of the session. It is the default, but if you use a different one, you should keep that in mind. (You can use the session_name() function to find it out.)

This code works because document.cookie is only ‘allowed to look at’ cookies that are associated with the current document (so external sites don’t stand a chance).

Conclusion

Cookies are a nice means of keeping sessions going. But when users of your web application perform sensitive tasks, you should not simply rely on a cookie for authentication.
The increasing possibilities of JavaScript can greatly enhance the usability of your application, but it also makes it harder for the browser (but also the developer) to keep things secure. Therefore, make sure sessions are airtight whenever there is interaction between the client and the server.

This is my first real article here, so if I forgot to mention basic things or something else, please tell me.