It’s rare that I open the source code for a random plugin and see every recommended security measure taken. When looking at Chris Boyd‘s plugin GeoLocation Plugin, I kept digging deeper and deeper and found he’d consistently covered everything. This plugin is a text book example of how to write a secure plugin.
Since he has so many techniques in here, this post wrote itself in my head. It was irresistible.
I strongly recommend you download the plugin and open geolocation.php to follow along
So, here are the security methods I saw him use, there may be more I didn’t catch, if so feel free to add them to the comments:
Use nonces on all input forms
Chances are your plugin will ask for information. A nonce is a security token that helps guarantee that you are getting real data from a real user. In function geolocation_inner_custom_box() Chris calls
echo '<input type="hidden" id="geolocation_nonce" name="geolocation_nonce"
value="' . wp_create_nonce(plugin_basename(__FILE__) ) . '" />';
to add the nonce to his input form and then to check this on the processing side in function geolocation_save_postdata he calls:
// Check authorization, permissions, autosave, etc
if (!wp_verify_nonce($_POST['geolocation_nonce'], plugin_basename(__FILE__)))
return $post_id;
This is very simple code. There’s almost no cost to adding nonces to form processing and you can use that exact code, just changing the name of the field. This will block most bots from abusing your plugin.
Verify the user’s permissions
The user_can functions go hand in hand with the nonces and they work together to block the same kind of attacks. If your plugin does something that just anyone off the street shouldn’t be able to do, verify that the user is allowed to do it. This check is just a little bit further into function geolocation_save_postdata:
if('page' == $_POST['post_type'] ) {
if(!current_user_can('edit_page', $post_id))
return $post_id;
} else {
if(!current_user_can('edit_post', $post_id))
return $post_id;
}
This simple check to confirm that the user is allowed to edit a post before the geotagging information is added and ties the plugin directly into all of the security already built into WordPress. It is tremendously powerful.
Configure default values
In programming 101, you learn never to trust the computer to give you a clean value for an uninitialized variable. In web development, there are even more implications to this. Caching is one of those. If you call get_option and WordPress does not have a value, it will access the database to see if there is a value set. Until a value is stored in the database, WordPress has to keep looking for it on every page load. Anything you can do that avoids accessing the database files and quite possibly the hard drives where the information is stored, will make your site run faster. If a value is found, that value will be loaded from the cache automatically. Additionally, if you set your default values, you know what you are getting back. Chris handles this in function default_settings():
function default_settings() {
if(get_option('geolocation_map_width') == '0')
update_option('geolocation_map_width', '450');
if(get_option('geolocation_map_height') == '0')
update_option('geolocation_map_height', '200');
if(get_option('geolocation_default_zoom') == '0')
update_option('geolocation_default_zoom', '16');
if(get_option('geolocation_map_position') == '0')
update_option('geolocation_map_position', 'after');
}
Use the Settings API and let WordPress do all the work
WordPress 2.7 added a wonderful set of tools called the Settings API. Most plugins do not take advantage of this complex tool set when they could. Chris uses the register_setting API call in function register_settings to enumerate the type of data he wants in each field.
function register_settings() {
register_setting( 'geolocation-settings-group',
'geolocation_map_width', 'intval' );
register_setting( 'geolocation-settings-group',
'geolocation_map_height', 'intval' );
register_setting( 'geolocation-settings-group',
'geolocation_default_zoom', 'intval' );
register_setting( 'geolocation-settings-group',
'geolocation_map_position' );
register_setting( 'geolocation-settings-group',
'geolocation_wp_pin');
}
As you can see he specifies that certain values must be integers. Chris doesn’t take full advantage of the API in this plugin. In fact, I’m not convinced that simply calling register_setting on its own does anything. It is meant to be used with other calls. Had he used them all WordPress could have handled all sorts of things for him automatically, including the nonce field and additional checks.
The settings API is POWERFUL but has a steep learning curve. Once you pass the learning curve your input form printing just becomes five lines:
<form action="options.php" method="post">
<?php settings_fields('plugin_options'); ?>
<?php do_settings_sections(__FILE__); ?>
<input name="Submit" type="submit"
value="<?php esc_attr_e('Save Changes'); ?>" />
</form>
This topic is WAAAAAAY to big to cover here and I freely admit, I’m no expert on it. I recommend that you read more: A quick & dirty example or The Whole Shebang
Verify your data
The last two topics are related as the come from the same rule: ALL data that you get from ANY source must be verified. This is where many plugins fail. The assumption is that “if it is in the database, it must be clean” or “it’s from an RSS feed, I know the data is good” or “The variable has INT in the name so it obviously contains an integer” or any of a thousand other gotyas. The way to keep yourself safe from an assumption is to VERIFY.
I want to highlight just two examples of this in Chris’s code.
First, in function display_location, he uses a cast to ensure the data he gets is what he wants from post meta:
$public = (bool)get_post_meta($post->ID, 'geo_public', true);
Second a function clean_coordinates uses regex to ensure the value he receives is what he wants:
$latitude = clean_coordinate($_POST['geolocation-latitude']);
[..]
function clean_coordinate($coordinate) {
$pattern = '/^(\-)?(\d{1,3})\.(\d{1,15})/';
preg_match($pattern, $coordinate, $matches);
return $matches[0];
}
Escape all variable data you display
I won’t show specific examples of this as they are everywhere throughout the whole plugin, but this is one of the most important steps you can take to make your plugin secure. It is also one of the areas that has has the most focus in the WordPress core over the years.
If you are displaying a value that isn’t hard coded in your source, you need to first feed it through one of these functions (or something similar):
esc_attr() Cleans HTML attributes for use on screen
esc_html() Prepares complete blocks of HTML code
esc_js() Special javascript handling of quotes and EOL characters
esc_sql() Escapes data for use in a query
esc_url() Returns a valid URL if possible
esc_url_raw() Prepares an URL to be inserted in a database
This applies to values you are putting into javascript, urls you are displaying on the screen or using for includes, and data used to build image references. All this information must be sanitized. Visit the codex for more information on data validation.
Bonus Tip
If you’ve made it this far in the post, you get one more tip for free. DON’T DO IT ALL YOURSELF. I’d be willing to wager that this plugin was not ‘born’ with all of these security techniques in place. Though this plugin is attributed to Chris in the repository, he lists multiple authors for the plugin. You don’t HAVE to do all of this by yourself. Once your plugin is done, ask people to review it. I can pretty much guarantee that someone will find something. That’s just how it works. But won’t you feel much better if your friend catches the problem before it is discovered because your plugin added an avenue of attack to every site it’s been installed on? Someone will be glad to review it for you it. That’s part of what is great about the WordPress community: people love to help.
Summation
Website security will forever be an on going battle. It is a big, complicated subject with nuances you can miss easily. However, WordPress has been around long enough to have build up quite a collection of tools you have at your disposal as a plugin author. If use the tools WordPress provides, following Chris’s example outlined here, you can rest easy at night knowing you’ve done your job well.