What are the common security flaws I need to look for?

3 comments

1. Here is a modified checklist, based on my current (work-in-progress) settings/data security checklist used for reviewing Themes (the principles should be no different for Plugins than they are for Themes):

   1. Plugins should prefix all options, custom functions, custom variables, and custom constants with plugin-slug.

   2. Plugins should implement Plugin Options and Plugin Settings pages deliberately, rather than relying on copy-and-paste scripts from website tutorials, such as the ones below, which are outdated, and do not include proper data security:

      • http://www.1stwebdesigner.com/wordpress/how-to-create-an-options-page-for-your-wordpress-theme/
      • http://wpshout.com/create-an-awesome-wordpress-theme-options-page-part-1

   3. Plugins should use the add_options_page() function to add the Plugin Settings Page to the Settings menu, rather than using add_menu_page() to add a top-level menu.

   4. Plugins should use an appropriate capability (e.g. manage_options) for the capability to add the settings page.

   5. Plugins should save options in a single array, rather than create multiple options for the settings page. The use of the Settings API (see below) would handle this.

   6. Plugins should use the Settings API(see below) to get and save form input data rather than rely on $_POST and $_REQUEST data directly.

   7. For checkboxes and select options, Plugins should use the checked() and selected() functions for outputting checked="checked" and selected="selected", respectively.

   8. Plugins should validate and sanitize all untrusted data before entering data into the database, and should escape all untrusted data before being output in the Settings form fields and before being output in the Theme template files:

      • http://codex.wordpress.org/Data_Validation

   9. Plugins should use esc_attr() for text inputs and esc_html() (or esc_textarea() in WP 3.1) for textareas.

   10. Plugins should explicitly provide Settings-page nonce checking, if not using the Settings API:

       • http://codex.wordpress.org/WordPress_Nonces

   11. It is also highly recommended that Plugins use the Settings API, which is easier to use, more secure, and takes care of a lot of the hard work of settings pages:

       • http://codex.wordpress.org/Settings_API

   For a good tutorial on using the Settings API, see:

   • http://www.chipbennett.net/2011/02/17/incorporating-the-settings-api-in-wordpress-themes/

   • http://planetozh.com/blog/2009/05/handling-plugins-options-in-wordpress-28-with-register_setting/

   If you want to check out a theme with a secure and solidly-coded theme settings page, check out this theme:
   http://wordpress.org/extend/themes/coraline

   Log in to Reply

2. There are two aspects to this:

   1. Basic principles.

      • Whatever is written into database should be checked for SQL injects.
      • Whatever is printed to screen should be checked that it doesn’t print harmful JavaScript.
      • Whenever someone does something it should be checked that it was his intention to do so and he has appropriate capability.
      • There are many many more things that you or me either won’t ever think to check for.

   2. Specifics.

      • Modern WordPress takes security seriously and aims to make it easy for developers.
      • So for most of things you want to do there is most likely a way to get it done with WP APIs.
      • So whatever you are doing your first step would be to fine and study appropriate API.
      • The further you are from common and simple functionality the more complex things you will need to study and implement.

   Log in to Reply
3. 1. Add defined('ABSPATH') or die('Access denied'); at every plugin’s script that used by wordpress directly
   2. Add empty index.php file at every directory
   3. Add .htaccess in plugin directory with needed instructions for prevent direct access to certain plugin’s files.

   Log in to Reply