How to secure wordpress plugins

In computer language “Security” often refers to scary buzzwords such as Cross site scripting, Cross site request forgery, SQL injection, vulnerabilities and holes.

You should be scared because these are real threats, as you will read, trivial to execute against shabby code. But then, you should not be scared because, fortunately, wordpress comes with all the tools you need to make your code safe and secure.

Securing Your Plugin

In wordpress’s environment, securing your plugin is not a difficult task, nor is it cumbersome or time consuming: wordpress implements several functions to address the various potentials issues.

User Permissions

You probably have already notice it when you try to access an admin page of a wordpress blog while being logged in as user that is not an administrator, you may be shown a message starting that you don’t have sufficient privileges, as shown in following image.

access-denied

To guarantee that specific actions are restricted to a population with specific rights, in other words to block privileges escalations attack, wordpress makes extensive use of a function named current_user_can(). You can use this function in your plugin.

How to check current_user_can()

The usage of current_user_can() is straightforward: you either check if a user has a capability or a role before proceeding to a relative action, or die with meaning message. For example:

 

 

Do not check too early

The function current_user_can() depends on get_currentuserinfo(), which has a particularity: It is a pluggable function. Pluggable function can be replaced by plugins. They can be found in file wp-includes/pluggable.php, which is loaded after active plugins.
Because of this particularity you cannot check user permissions at plugin loading and instead will need to wait until wordpress has fully started and instantiated. For example, picture a plugin that output debug information when you append ?debug=1to any url of the blog, but only if the user is an administrator.

The debug output function here prints out all SQL queries that wordpress ran, provided that the constant SAVEQUERIES is set to true.

Now how can you make this function dependent on the query parameter debug=1?

The worst way to do so would be following:

This is bad practice because following information can potentially reveal sensitive information such as physical information such as physical paths or tables names, and with such a conditional test, any one would see them by simply adding ?debug=1 to any url of the site.

Because you want to restrict debug data to the administrator of a blog, you need to code a more revealed condition:

But this won’t work: Remembers, when the plugin is loaded and server parser and compile its code, pluggable functions are not in memory yet. What you are needed to do is to hook this check to an action that occurs only when everything is loaded.

In your plugins, always hook function calls to an appropriate action, such as ‘init‘ or ‘plugins_loaded‘. This way you can ensure that all wordpress functions have been loaded and your function won’t be triggered too soon.