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

16

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!

MrBatman
fuente

Respuestas:

16

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:

  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:

  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:

  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:

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

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

Chip Bennett
fuente
Y debo agregar: si alguien ve algo que falta en la lista, por favor comente , para que pueda agregarlo a la lista de verificación, para ayudar a mejorar la revisión de seguridad de Temas.
Chip Bennett
Wow, gran lista, gracias. Me pregunto si vale la pena hacer que esta pregunta sea un wiki comunitario y que cada uno de estos puntos sea su propia respuesta para permitir una mejor discusión y elaboración.
goldenapples
Estaría bien con eso, pero no quiero secuestrar la pregunta del póster original (a menos que así se hagan las cosas en StackExchange? Todavía soy nuevo aquí ...).
Chip Bennett
No sé tampoco ... déjelo a discreción de los moderadores, supongo. Parece que sería una gran pregunta para la wiki, ya que sus mejores prácticas y tan importantes todavía se están resolviendo. @Rarst?
goldenapples
¿Podría crear una nueva pregunta, si es necesario?
Chip Bennett
11

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.
Rarst
fuente
1
  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.
egor
fuente