SSL all the things

Security is important and one of the things I would like to see is if we can enforce a requirement for all requests that core makes back to WordPress.org for updates and information to be https. This is the a great step to a greater level of update verification to help detect man-in-the-middle attacks.

Making this switch is going to be a fun journey and we are bound to find that there are some setups that can’t/don’t/won’t support https with the WP_HTTP API.

So before we try switching to using https in trunk I’ve update the Beta Tester plugin so that it forces all requests to api.wordpress.org to happen over https. I’ve also updated the api so that if you make a https request it will return https references in the results.

Please go for and test this on your test installs and let us know of any issues you find here in the comments or on the trac ticket.

Making your broken Plugin work again with WordPress 2.8.1

WordPress 2.8.1 contains changes to improve the security of plugins by ensuring that only correctly registered plugin pages can be accessed as well as only showing the link to the page to users who have the capability required in the add_x_page call.

This change has broken a number of plugins which were adding there menus on the wrong action hook bypassing some capability checks.

The correct hook to use, as documented in the codex, is admin_menu. However, some plugins have successfully in the past been using admin_init but this meant that they bypassed some of the capability checking that WordPress does to help limit access to plugins pages.

This capability checking is there to help limit access to plugin added pages but plugins must always use current_user_can() to check the capability they require to ensure they prevent access to incapable users.

The code to look for in your plugins is something like this:

add_action('admin_init', 'my_plugin_menu');

function my_plugin_menu() {
  add_options_page('My Plugin Options', 'My Plugin', 'manage_options', 'your-unique-identifier', 'my_plugin_options');
}

Which should be:

add_action('admin_menu', 'my_plugin_menu');

function my_plugin_menu() {
  add_options_page('My Plugin Options', 'My Plugin', 'manage_options', 'your-unique-identifier', 'my_plugin_options');
}

And don’t forget while checking your plugin for this issue go and check to make sure you use current_user_can() to check user capabilities before allowing them to access your plugin page functionality.

WordPresz

It seems there has been an attempt recently to distribute a trojaned version of WordPress via some form of phishing scam.  It seems this attack relied on exploiting an old version of WordPress which had not been upgraded and changing it to point at a different site for one of the dashboard feeds.  The site was then offering a trojaned install of a version of WordPress 2.6.4 which does not exist.  The site has now been shutdown so it is nolonger possible to get hold of this Trojaned version but it does highlight the importance of upgrading when a security release is made.

As I have said in my response in the article on The Register

We recommend that people upgrade as soon as possible when we release a security release so as to ensure they are not vulnerable to issues which will likely have exploits in the wild. Also in the upcoming 2.7 release of WordPress we are including a built-in upgrade mechanism within WordPress which will allow people to upgrade automatically with ease.

I would however stress the need with any piece of software to check that an upgrade is real by visiting the website of the software provider manually rather than relying on a link that you have been provided. Otherwise, as with bank phishing scams there is the potential for someone to trick you into doing something you didn’t want to do.

making the default install more secure

WordPress 2.6 will be more secure out-of-the box including better support for running the admin over SSL and changes to disable the remote publishing protocols by default.

We have choosen to disable Atom Publishing Protocol and the variety of XML-RPC protocols by default as they expose a potential to be a security risk.  So from WordPress 2.6 onwards you will need to go into the Settings->Write page and enable them individually if you want to use them.

WordPress weekly digest 24th March to 29th March 2008

It was a busy week again for WordPress 2.5, this list look short as we have been doing the final polishing on today’s WordPress 2.5 release, the changes were:

• A fix to ensure that we preserve HTML entities in Custom Fields (#6374).
• Pretty permalinks for taxonomies (#6357).
• Changes to the login page redirect code to ensure that we honour redirect_to for logged in users (#6385).
• A new filter to allow a plugin to force enable/disable the flash uploader (#6406).
• Switch to using is_numeric() instead of ctype_digit() (#5481).
• A change to the trackback handling code to drop trackbacks that request UTF-7 ([7559]).
• Some updates to the new admin style.

For even more information on some of the other little changes that went in this week you can read the whole weekly trac timeline.

Now go an update to WordPress 2.5 – you know you want to!

WordPress weekly digest 25th February to 3rd March 2008

Firstly, apologies again for this digest post being a bit late – the final push for 2.5 has been in full swing and I took a week out to go on holiday. It was a busy week again for WordPress 2.5, the changes were:

• Changes to do_feed() to ensure that an error page is generated when a non-existent feed format is requested (#5446).
• Introduction of a new image_resize() function (#6005).
• Introduction of get_temp_dir() to allow for the different locations temporary files may be stored (#5984).
• An update to the in_category() function to support category names that are all numbers and add documentation ([7064]).
• Change to generating random passwords for users created during import (#5837).
• A fix to the WXR importer to ensure that tags are imported correctly by name rather than as numbers (#5330).
• A fix to ensure that the current_page_item class is set correctly when listing pages (#2959).
• Introduction of get_post_ancestors() and the addition of the current_page_ancestor class to ancestors of the current page when listing pages (#5662).
• Fixes to the plugin update code to use string comparison to detect version differences (#5978).
• Introduction of post editing collision detection (#6043).
• Changes to switch preg_replace() calls with the e modifier to preg_replace_callback() to improve security ([7056], #5644).
• Update to TinyMCE 3.02 (#6012).
• More updates to the new media library (#5911).
• Lots of updates to the new admin style.

For even more information on some of the other little changes that went in this week you can read the whole weekly trac timeline, look at a complete changelog for trunk or view a diffstat of the changes.