9 Maneras de hacer tu Drupal más seguro

drupal_0.jpg
Solucionex
09
Mayo 19

La seguridad es muy difícil de conectar a cualquier software o producto después de que se haya construido. Construirlo en el núcleo del código ayuda a evitar errores y, por lo tanto, la próxima versión de Drupal 8 intenta generar más seguridad de forma predeterminada, al tiempo que sigue siendo utilizable para desarrolladores y constructores de sitios.

Vamos a hacer una lista de 9 consejos para hacer tu Drupal más seguro:

  1. El uso de PHP como formato de importación para la configuración:

    • Drupal 8 no incluye el formato de entrada de PHP en el core. Además de alentar las mejores prácticas (administrar código en un sistema de control de revisión como git), esto significa que Drupal ya no hace que sea trivial escalar un inicio de sesión de administrador para poder ejecutar código PHP o comandos de shell arbitrarios en el servidor. 


      Para Drupal 7, importar algo como una Vista requería importar código PHP ejecutable, y para ciertas configuraciones de visibilidad de bloque personalizadas, etc. necesitaría ingresar un fragmento de código PHP. Todos estos usos de PHP evaluado (exponiendo posibles vulnerabilidades de ejecución de código) han desaparecido; consulte el siguiente punto sobre la administración de la configuración.


      Ahora que hemos cubierto los dos primeros, el resto de los 10 están en un orden bastante arbitrario.

    • Drupal 7 block.tpl.php 
    •            drupal7

    • Drupal 8 block.html.twig: 
    •         drupal8

     

  2.  

  3. Configuración del sitio exportable, manejable como código y versionable:

    • La Configuration Management Initiative (CMI) transformó la forma en que Drupal 8 gestiona las cosas que se habrían representado en Drupal 7 como código PHP. Cosas como variables de Drupal o exportables ctools (por ejemplo, vistas exportadas).



      CMI usa YAML como formato de exportación e importación y los archivos YAML pueden administrarse junto con su código y registrarse en un sistema de control de revisiones (como git). 


      ¿Por qué es esto una mejora de seguridad? Bueno, además de eliminar el uso del código PHP como un formato de importación (y, por lo tanto, una posible vulnerabilidad de ejecución del código), el seguimiento de la configuración en el código hace que sea mucho más fácil tener un historial auditable de los cambios de configuración. Esto hará que Drupal sea más atractivo y adecuado para las empresas que necesitan controles estrictos sobre los cambios de configuración implementados. Además, la configuración se puede probar completamente en el desarrollo y luego se puede replicar exactamente en producción al mismo tiempo que cualquier cambio de código correspondiente (evitando errores durante la configuración manual). Finalmente, es posible bloquear completamente los cambios de configuración en la producción para forzar el despliegue de cambios como código.


  4.  

  5. Entrada de contenido de usuario y filtrado mejorado

    Si bien la integración de un editor WYSIWYG con el núcleo de Drupal es una gran mejora de la usabilidad, se tomó un cuidado especial para mitigar las prácticas deficientes que al agregar un editor WYSIWYG alentaba en versiones anteriores de Drupal. En particular, a los usuarios con acceso al editor a menudo se les otorgaba acceso al formato de texto html completo, lo que efectivamente les permitía ejecutar ataques XSS en cualquier otro usuario del sitio.



    Para alentar la mejor práctica de solo permitir el uso del formato HTML filtrado, la configuración del editor WYSIWYG de Drupal 8 se integra con el filtro de texto correspondiente. Cuando se agrega un botón a la configuración activa, la etiqueta HTML correspondiente se agrega a la lista permitida para el filtro de texto.


    • Arrastre un nuevo botón de la sección disponible para habilitar en la configuración del editor:
    • editor
    • La etiqueta HTML correspondiente (la etiqueta U) se agrega a la lista permitida:

    • tag

    • Una mejora de seguridad adicional es que el filtro de texto principal admite limitar a los usuarios a usar solo imágenes locales del sitio, lo que ayuda a prevenir la falsificación de solicitudes entre sitios (CSRF) y otros ataques o abusos que usan imágenes.

  6.  

  7. Contraseñas de inicio de sesión más seguras:

    • Hay tres mejoras distintas en el manejo de cookies de sesión y sesión.

      Primero, la seguridad de los identificadores de sesión se ha mejorado enormemente contra la exposición a través de copias de seguridad de bases de datos o inyección de SQL ( puerto posterior 7.x ). Anteriormente, en Drupal, el ID de sesión se almacena y se verifica directamente en la cookie de sesión entrante desde el navegador. El riesgo de esto es que el valor de la base de datos se puede utilizar para rellenar la cookie en el navegador y así asumir la sesión y la identidad de cualquier usuario que tenga una sesión válida en la base de datos. En Drupal 8, el ID se hasheado antes del almacenamiento, lo que impide que el valor de la base de datos se utilice para asumir la sesión de un usuario, pero el valor entrante del valor simplemente se hash para verificar el valor.


      A continuación, se eliminó del núcleo el soporte de sesión SSL en modo mixto. Originalmente, el soporte de sesión SSL de modo mixto se agregó al núcleo para admitir sitios que, por ejemplo, usaban módulos contribuidos para servir a la página de inicio de sesión a través de SSL mientras que otras páginas no estaban encriptadas. Sin embargo, esta es una mala práctica. Tendrá que reemplazar el servicio de manejo de sesiones si realmente lo necesita. Esto fomenta la publicación de todo su sitio a través de SSL (que también es un aumento de la clasificación del motor de búsqueda).



      El cambio final es que la "www" principal ya no se elimina del dominio de la cookie de sesión, ya que hace que la cookie de la sesión se envíe a todos los subdominios.

  8.  

  9. Protección de token CSRF automatizada en definiciones de ruta:

    • Los enlaces (solicitudes GET) que causan alguna acción destructiva o cambio de configuración deben protegerse de CSRF, generalmente con un token específico del usuario en la cadena de consulta que se verifica antes de llevar a cabo la acción.

      

Este cambio mejora la experiencia y la seguridad del desarrollador al automatizar un proceso frecuentemente olvidado o realizado incorrectamente en los módulos aportados. Además, la centralización del código facilita la auditoría y proporciona cobertura de prueba.

      Drupal 8 lo hace fácil. Un desarrollador simplemente necesita especificar que una ruta (una ruta del sistema en términos de Drupal 7) requiere un token CSRF. Este es un ejemplo de la definición de ruta YAML para un enlace protegido en la entidad Drupal 8.

    • code

    • Solo se debe agregar una línea en la sección de requisitos: para proteger la eliminación de accesos directos de CSRF.

  10.  

  11. Patrones de host de confianza aplicados para las solicitudes:

    • Muchos sitios de Drupal responderán a una solicitud de página utilizando un encabezado de host arbitrario enviado a la dirección IP correcta. Esto puede provocar envenenamiento de caché, correos electrónicos de sitios falsos, enlaces de recuperación de contraseñas falsos y otros problemas con implicaciones de seguridad.

      Para versiones anteriores de Drupal, puede ser un desafío configurar correctamente el servidor web para un sitio único que usa sitios / predeterminado como su directorio de sitios para evitar estos ataques de suplantación de encabezados de host. Drupal 8 se envía con una facilidad sencilla para configurar los patrones de host esperados en settings.php y le advierte en el informe de estado del sitio si no está configurado.

  12.  

  13. DOP MySQL limitado a la ejecución de sentencias individuales:

    • Si está disponible, Drupal 8 establecerá un indicador que limita a PHP a enviar solo una sola declaración SQL a la vez cuando se usa MySQL. Este cambio habría reducido la gravedad de SA-CORE-2014-005 (una vulnerabilidad de inyección de SQL que fue fácilmente explotada por usuarios anónimos) ( 7.x back-port ). Lograr este cambio en Drupal 8 significó que primero tuve que aportar un pequeño cambio ascendente al lenguaje PHP en sí mismo, y a la biblioteca MySQL de PDO que está disponible en las versiones 5.5.21 o 5.6.5 de PHP y superiores.
  14.  

  15. Protección de clickjacking habilitada por defecto

    • Un pequeño cambio, pero Drupal 8 envía el encabezado X-Frame-Options: SAMEORIGIN en todas las respuestas de forma predeterminada. Este encabezado es respetado por la mayoría de los navegadores e impide que el sitio se sirva dentro de un iframe en otro dominio. Esto bloquea los llamados ataques de click-jacking (por ejemplo, formas o enlaces en el sitio que se presentan de forma encubierta en el sitio de un atacante dentro de un iframe), así como el bloqueo de la reutilización no autorizada del contenido del sitio a través de iframes. ( 7.x back-port ).
  16.  

  17. API de JavaScript principal compatible con CSP

    • El soporte para JavaScript en línea se eliminó de la propiedad #attached en la API de representación de Drupal. Además, las variables de configuración de JavaScript de Drupal ahora se agregan a la página como datos JSON y se cargan en una variable en lugar de representarse como JavaScript en línea. Este fue el último uso de JavaScript en línea por el núcleo de Drupal 8, y significa que los creadores de sitios pueden habilitar mucho más fácilmente una estricta política de seguridad de contenido (CSP), un nuevo estándar web para comunicar las restricciones por sitio a los navegadores y mitigar el XSS y otras vulnerabilidades. 
  18.