¿Cuáles son las fallas de seguridad comunes que debo buscar? [cerrado]

Como desarrollador de un plugin WP aspirante, ¿cuáles son los principales defectos / agujeros de seguridad que debo buscar?

Estoy a punto de crear un nuevo complemento con un panel de configuración (es decir, campos de entrada y demás). ¿De qué debería preocuparme?

Por ejemplo, ¿la desinfección de datos es tan importante ya que está en el área / wp-admin /? ¿Podría alguien malicioso golpear directamente mi página de complementos y enviar solicitudes POST o algo así?

¡Gracias!

Aquí hay una lista de verificación modificada, basada en mi configuración actual (trabajo en progreso) / lista de verificación de seguridad de datos utilizada para revisar Temas (los principios no deberían ser diferentes para Plugins que para Temas):

1. Los complementos deben prefijar todas las opciones, funciones personalizadas, variables personalizadas y constantes personalizadas con plugin-slug.

2. Los complementos deben implementar las páginas de Opciones de complementos y Configuración de complementos de forma deliberada, en lugar de depender de los scripts de copiar y pegar de los tutoriales del sitio web, como los que se muestran a continuación, que están desactualizados y no incluyen la seguridad de datos adecuada:

   • 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. Los complementos deben usar la add_options_page()función para agregar la página de configuración de complementos al Settingsmenú, en lugar de usar add_menu_page()para agregar un menú de nivel superior.

4. Los complementos deben usar una capacidad apropiada (por ejemplo manage_options) para agregar la página de configuración.

5. Los complementos deben guardar las opciones en una sola matriz, en lugar de crear múltiples opciones para la página de configuración. El uso de la API de configuración (ver más abajo) manejaría esto.

6. Plugins deben utilizar la API de configuración (ver más abajo) para obtener y guardar los datos del formulario de entrada en lugar de depender $_POSTy $_REQUESTdatos directamente.

7. Para casillas de verificación y opciones de selección, los complementos deben usar las funciones checked()y selected()para la salida checked="checked"y selected="selected", respectivamente.

8. Los complementos deben validar y desinfectar todos los datos no confiables antes de ingresar datos en la base de datos, y deben escapar de todos los datos no confiables antes de que se muestren en los campos del formulario Configuración y antes de que se muestren en los archivos de plantilla del Tema:

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

9. Los complementos deben usarse esc_attr()para entradas de texto y esc_html()(o esc_textarea()en WP 3.1) para áreas de texto.

10. Los complementos deben proporcionar explícitamente la comprobación de nonce de la página de configuración, si no se utiliza la API de configuración:

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

11. También se recomienda encarecidamente que los complementos utilicen la API de configuración, que es más fácil de usar, más segura y se ocupa del trabajo arduo de las páginas de configuración:

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

Para un buen tutorial sobre el uso de la API de configuración, consulte:

• 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/

Si desea consultar un tema con una página de configuración de tema segura y sólidamente codificada, consulte este tema:
http://wordpress.org/extend/themes/coraline

Hay dos aspectos para esto:

1. Principios básicos.

   • Lo que esté escrito en la base de datos debe verificarse para inyecciones SQL.
   • Lo que se imprima en la pantalla debe verificarse para que no imprima JavaScript dañino.
   • Siempre que alguien haga algo, debe comprobarse que era su intención hacerlo y que tiene la capacidad adecuada.
   • Hay muchas cosas más que usted o yo nunca pensaremos en verificar.

2. Detalles específicos.

   • WordPress moderno toma en serio la seguridad y tiene como objetivo facilitar a los desarrolladores.
   • Entonces, para la mayoría de las cosas que desea hacer, lo más probable es que haya una manera de hacerlo con las API de WP.
   • Entonces, lo que sea que esté haciendo, su primer paso sería multar y estudiar la API adecuada.
   • Cuanto más lejos esté de la funcionalidad común y simple, más complejas necesitará estudiar e implementar.

1. Agregue defined('ABSPATH') or die('Access denied');en cada script de plugin que use wordpress directamente
2. Agregue un archivo index.php vacío en cada directorio
3. Agregue .htaccess en el directorio de complementos con las instrucciones necesarias para evitar el acceso directo a ciertos archivos de complementos.