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

14

Como un aspirante a desarrollador de complementos de WP, ¿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). ¿Qué debería preocuparme?

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

¡Gracias!

    
pregunta MrBatman 30.03.2011 - 18:34

3 respuestas

16

Aquí hay una lista de verificación modificada, basada en mi configuración actual (trabajo en curso) / lista de verificación de seguridad de datos utilizada para revisar Temas (los principios no deberían ser diferentes para los Plugins que para los 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 complemento y Configuración de complemento de forma deliberada, en lugar de confiar en las secuencias de comandos 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:

  3. Los complementos deben usar la función add_options_page() para agregar la página de configuración de complementos al menú Settings , en lugar de usar add_menu_page() para agregar un menú de nivel superior.

  4. Los complementos deben usar una capacidad adecuada (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. Los complementos deben usar la API de configuración (ver más abajo) para obtener y guardar los datos de entrada del formulario en lugar de confiar directamente en los datos $_POST y $_REQUEST .

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

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

  9. Los complementos deben usar esc_attr() para las entradas de texto y esc_html() (o esc_textarea() en WP 3.1) para textareas.

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

  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 de gran parte del arduo trabajo de las páginas de configuración:

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

Si desea revisar un tema con una página de configuración de tema segura y codificada sólidamente, consulte este tema:
enlace

    
respondido por el Chip Bennett 30.03.2011 - 20:52
11

Hay dos aspectos en esto:

  1. Principios básicos.

    • Lo que está escrito en la base de datos debe verificarse para las inyecciones de SQL.
    • Todo lo que se imprima en la pantalla debe comprobarse que no imprima JavaScript dañino.
    • Cada vez que alguien hace algo, se debe verificar que su intención sea hacerlo y que tenga la capacidad adecuada.
    • Hay muchas más cosas que ni tú ni yo pensaremos en buscar.
  2. Especificaciones.

    • WordPress moderno toma la seguridad en serio y apunta a facilitar la tarea a los desarrolladores.
    • Por lo tanto, para la mayoría de las cosas que quieres hacer, lo más probable es que haya una forma de hacerlo con las API de WP.
    • Entonces, lo que sea que esté haciendo en su primer paso sería multar y estudiar la API apropiada.
    • Cuanto más lejos estés de la funcionalidad común y simple, más cosas complejas necesitarás estudiar e implementar.
respondido por el Rarst 30.03.2011 - 21:04
1
  1. Agregue defined('ABSPATH') or die('Access denied'); a cada script de complemento 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.
respondido por el egor 01.09.2012 - 14:35

Lea otras preguntas en las etiquetas