Tipo de artículo: Artículo original Temática: Soluciones Informáticas
Recibido: 23/08/2019 | Aceptado: 21/09/2019 | Publicado: 22/09/2019
Fortalecimiento de la seguridad en drupal sin utilizar
complementos
Strengthening drupal security without using complements
Leobel Rodríguez Chang1*, Leonardo Aguilera Blanco2
1 Universidad de las Ciencias Informáticas, Cuba, lrchang@uci.cu, Carretera a San Antonio de los Baños Km 2 ½, La Lisa, La Habana, Cuba.
2 Universidad de las Ciencias Informáticas, Cuba, laguilera@uci.cu, Carretera a San Antonio de los Baños Km 2 ½, La Lisa, La Habana, Cuba.
Resumen
Los ciberataques contra aplicaciones web con el pasar de los años han ido en aumento. Estos incidentes se han visto orientados a las partes del sistema que permiten que una aplicación web funcione, como son los servidores web, los sistemas de gestión de contenido de código abierto (CMS), las bases de datos entre otros. Dentro de ellos los CMS son uno de los más atacados. Drupal es uno de estos CMS y es un sistema muy popular y muy usado en la actualidad, solo superado por Wordpress. Por eso este documento describe las configuraciones de seguridad que permiten mantener una aplicación web de Drupal segura. Drupal tiene un fuerte modelo de seguridad, pero como cualquier aplicación, requiere que se le agreguen configuraciones para un ambiente fuera del entorno de desarrollo. El objetivo que se persigue es propiciar una guía que sin agregar ningún elemento permita asegurar la aplicación. Mediante pruebas y su utilización en variadas aplicaciones web se demostró que con el uso de estas configuraciones se garantizaba una seguridad adecuada y robusta que permitía disminuir los riesgos y amenazas.
Palabras clave:Configuraciones, Despliegue Seguro, Drupal, Hardening, Seguridad Informática.
Abstract
management systems (CMS), databases, among others. Within them the CMS are one of the most attacked. Drupal is one of these CMS and it is a very popular system and widely used today, only surpassed by Wordpress. That's why this document describes the security settings that allow you to maintain a secure Drupal web application. Drupal has a strong security model, but like any application, it requires that you add settings for an environment outside of the development environment. The objective pursued is to promote a guide that, without adding any element, allows ensuring the application. Through tests and their use in various web applications it was demonstrated that the use of these configurations guaranteed an adequate and robust security that allowed diminishing the risks and threats.
Keywords: Configurations, Secure Deployment, Drupal, Hardening, Computer Security
Introducción
Las aplicaciones web han ido tomando el dominio del internet y con ello se han convertido en un pilar fundamental de la sociedad moderna. Todos los días más aplicaciones web nacen y ven su primera luz en un ambiente hostil, vulnerable, con amenazas como realmente es el internet.
Drupal es un sistema de gestión de contenido de código abierto (CMS) que facilita un rápido despliegue de estas aplicaciones web. Se utiliza para crear muchos de los sitios web y aplicaciones que se utilizan hoy en día. Drupal tiene excelentes características estándar, como la creación de contenido fácil, un rendimiento confiable y una excelente seguridad. Pero lo que lo distingue es su flexibilidad; La modularidad es uno de sus principios fundamentales. Sus herramientas lo ayudan a crear el contenido versátil y estructurado [5].
Aunque uno de sus fuertes es la seguridad, Drupal recibe ataques dirigidos a vulnerabilidades que son dejadas por los administradores o por funcionalidades que para un ambiente de despliegue se encuentran mal configuradas, otras son vulnerabilidades que se encuentran en su misma configuración, cosa que se ven resueltas con las nuevas versiones liberadas por sus desarrolladores. En la actualidad tenemos dos puntos fundamentales sobre esta última que son las mayores amenazas. Estas son las bases tecnológicas desactualizadas que constituyen un escenario común que por malas prácticas y una administración deficiente se convierte en una amenaza y las vulnerabilidades cubiertas sin parches liberados el cual sería el peor escenario ya que los atacantes conocen la vulnerabilidad para explotarla y no existe manera de solucionarlo.
posibilidades de que estos tengan éxito. La seguridad no puede ser solo una palabra de moda, es un proceso que debe estar arraigado en la cultura de una organización.
Materiales y Métodos
Para la realización de la investigación se emplearon los siguientes métodos de investigación:
Histórico-lógico: Se utilizó para el estudio de la evolución de las medidas de seguridad en Drupal.
Análisis-Síntesis: Se empleó para extraer las características principales y comparar las diferentes medidas
nativas para el fortalecimiento de la seguridad en instalaciones de Drupal.
Experimentación: Se utilizó para la realización de despliegues de pruebas y puesta a punto de los métodos y configuraciones propuestas como parte de la investigación, tanto en entornos simulados como reales.
La versión de Drupal emplea fue la 8.6.10, instalada sobre Apache 2.4.29 y Ubuntu Server 18.04.
Resultados y discusión
Antes de abordar las configuraciones internas, es importante enumerar las principales medidas básicas de seguridad que se presupone que los administradores han aplicado:
Eliminar el usuario Admin y no emplear nombres de usuario que tengan relación con su función en la
aplicación web como editor, autor, administrador u otro.
Utilizar contraseñas generadas por servicios y programas especializados para incrementar su fortaleza. Esto se
aplica tanto a las contraseñas de administración como a la de conexión con la base de datos y otros servicios.
Eliminar temas (themes) y complementos (plugins) que no se utilicen.
Mostrar el alias o nickname del usuario en lugar del nombre de la cuenta o username.
Instalar un Firewall de Aplicaciones Web como All In One WP Security & Firewall.
Estas son las configuraciones iníciales de seguridad que por defecto toda instalación basada en Drupal debe tener. A continuación, se describirán cada una de las medidas avanzadas propuestas [8].
Borrado de archivos residuales del proceso de instalación
puede determinarse la versión base del núcleo de Drupal o simplemente saber que se está en presencia de una. Para evitarlo es recomendable eliminar cada uno de estos archivos [15].
En la raíz del sitio:
1) ./INSTALL.txt
2) ./README.txt
3) ./LICENSE.txt En el core:
1) ./core/CHANGELOG.txt
2) ./core/install.php
3) ./core/INSTALL.txt
4) ./core/INSTALL.mysql.txt
5) ./core/INSTALL.pgsql.txt
6) ./core/INSTALL.sqlite.txt
7) ./core/LICENSE.txt
8) ./core/MAINTAINERS.txt
9) ./core/UPGRADE.txt En sites:
1) ./sites/README.txt
2)
./sites/default/files/config_Z3bmbT-W7k_yXy_ffwQgdG56j2xy8duvkn8kU7ysK8QT3UtHyAIVg_rP_xdxT03hUQyTydG7Iw/sync/README.tx t
En modules:
1) ./modules/README.txt
2) ./modules/*/README.txt En themes y ./core/themes:
1) ./themes/README.txt
3) ./core/themes/*/nombre_tema.info.yml
4) ./core/themes/*/info.yml En Component:
1) ./core/lib/Drupal/Component/README.txt
2) ./core/lib/Drupal/Component/*/README.txt
Los * significan todos los posibles nombres que puedan tener los temas, componentes y módulos.
Supresión del metadato Generator y patrón versión
El metadato Generator es el principal responsable de informar la versión del núcleo de Drupal, información muy valiosa para los ciberdelincuentes, los cuales lo utilizan para acotar el rango de exploit que son necesarios utilizar para evadir las medidas de seguridad [1].
Para hacer esto, se debe añadir la siguiente función en el fichero drupal/core/themes/bartik/bartik.theme, se debe sustituir bartik por el nombre del tema que se esté utilizando:
function bartik_page_attachments_alter(array &$attachments) {
foreach ($attachments['#attached']['html_head'] as $key => $attachment){ if ($attachment[1] == 'system_meta_generator') {
unset($attachments['#attached']['html_head'][$key]); }
} }
En caso de que se desee cambiar el tema se debe volver a realizar estos cambios.
Cambiar los permisos del directorio
Se recomienda que los directorios de la instalación tengan asignados permisos 755 (drwxr-xr-x). Esto significa que solo el propietario de los directorios tendrá acceso completo a estos y los demás solo podrán leer el contenido pero no crear archivos ni borrarlos [10].
En el caso de los archivos se deben establecer permisos 644 (-rw-r--r--), de manera que solo el propietario pueda leer y escribir en estos, mientras que todos los demás sólo puedan leerlos [10].
find /var/www/html/drupal/ -type d -exec chmod 755 {} \;
find /var/www/html/drupal/ -type f -exec chmod 644 {} \;
Algunas instalaciones pueden requerir el establecimiento de permisos específicos. Lo importante es que se analice cada caso y se aplique el principio de menor privilegio. Para ello siempre debe tenerse en cuenta la función de los directorios de Drupal como se explican a continuación:
/ (directorio raíz) solo la cuenta de usuario del webmaster debe tener permiso de escritura sobre los archivos, excepto el .htaccess si se desea que Drupal gestione automáticamente las reglas contenidas en este.
core/includes/ (lógica de funcionamiento) solo la cuenta de usuario del webmaster debe tener permiso de escritura.
core/profiles/ (archivos de complementos) solo la cuenta de usuario del webmaster debe tener permiso de escritura, módulos para los perfiles de instalación.
core/themes/ (archivos de temas) Si se utiliza el editor de temas, todos los archivos necesitan tener permisos de escritura por el proceso del servidor web, de otro modo, solo la cuenta de usuario del webmaster debe tener permiso de escritura.
core/modules/ (archivos de complementos) solo la cuenta de usuario del webmaster debe tener permiso de escritura. Módulos propios del core de Drupal.
Cambiar la ubicación del archivo settings.php
El archivo .sites/default/settings.php contiene una serie de informaciones sensibles para la administración de Drupal. Para evitar el intento de acceso a este, se debe copiar el fichero a una ubicación designada y en el que se queda en el directorio .sites/default/ se debe borrar todo y dejar el siguiente comando:
require “/dirección/desde/la_raíz/hasta_el_fichero_real”;
Deshabilitar el registro de usuarios si no va ser utilizado
La explotación de un número considerable de vulnerabilidades en los CMS depende de la creación de un usuario [13]. Se recomienda que las aplicaciones web que no tengan un sistema de registro de usuario deshabilite esta funcionalidad o que la restrinja a solo los administradores como es el caso de ejemplo:
Acceder al panel de administración.
En el menú de arriba se va a Configuration
En la sección de Registration and cancellation} se va a Who can register accounts? y se marca la opción Administrators only
Limitando la publicación de mensajes de error
La exposición de los mensajes de error es muy útil en la etapa de desarrollo y configuración, pero luego es contraproducente porque estos pueden exponer información sensible y en sentido general no debe ser mostrado en los resultados HTML [2].
Acceder al panel de administración.
En el menú de arriba se va a Configuration
En la sección de development se va a Logging and errors
En la opción Error messages to display se cambia a None
Modificar los valores de los generadores de claves por defecto
En drupal el valor hash_salt se usa para enlaces de inicio de sesión únicos, cancelar enlaces, tokens de formularios. Esta variable se establecerá en un valor aleatorio por el instalador. Todos los enlaces de inicio de sesión de una sola vez se invalidarán si se cambia el valor. Tenga en cuenta que si su sitio se implementa en un grupo de servidores web, debe asegurarse de que esta variable tenga el mismo valor en cada servidor.
Para mayor seguridad, puede establecer esta variable en el contenido de un archivo fuera de la raíz de su documento; También debe asegurarse de que este archivo no esté almacenado con copias de seguridad de su base de datos [2]. Para modificar el valor hash_salt se va al fichero drupal/sites/default/settings.php
Este fichero contiene los datos de la base de datos y los valores que se ponen a continuación. $settings['hash_salt'] = 'clave';
$config_directories['sync'] = 'sites/default/files/config_xxx';
xxx es un valor al azar que drupal pone cuando se instala. Se recomienda cambiar la ubicación del fichero config_xxx, para esto solo se debe mover a otro directorio y cambiar la dirección que la variable config\_directories['sync'] es decir:
$settings['hash_salt'] = 'clave';
$config_directories['sync'] = 'nueva/dirección/config_xxx';
Procesamiento de caracteres y codificaciones especiales
El módulo de filtro permite a los administradores configurar formatos de texto. Los formatos de texto cambian la forma en que las etiquetas HTML y otros textos se procesarán y mostrarán en el sitio. Se utilizan para transformar texto, y también ayudan a defender su sitio web contra la entrada potencialmente dañina de usuarios malintencionados. Los editores de texto visuales pueden asociarse con formatos de texto utilizando el módulo Editor de texto [17]. Para obtener más información, consulte la documentación en línea para el módulo de filtro.
Para acceder al panel de este modulo se siguen los siguientes pasos:
Acceder al panel de administración.
En el menú de arriba se va a Configuration
En la sección de Content authoring se va a Text formats and editors En esta sección se puede:
Gestión de formatos de texto. Puede crear y editar formatos de texto en la página de formatos de texto (si el módulo Editor de texto está habilitado, esta página se denomina editores y formatos de texto). Se incluye un formato de texto por defecto: Texto sin formato (que elimina todas las etiquetas HTML). Se pueden crear formatos de texto adicionales durante la instalación. Puede crear un formato de texto haciendo clic en "Agregar formato de texto".
Asignación de roles a formatos de texto. Puede definir qué usuarios podrán usar cada formato de texto seleccionando roles. Para garantizar la seguridad, los usuarios anónimos y no confiables solo deberían tener acceso a formatos de texto que los restringen a texto sin formato o un conjunto seguro de etiquetas HTML. Esto se debe a que las etiquetas HTML pueden permitir la inserción de enlaces o scripts maliciosos en el texto. A los usuarios registrados más confiables se les puede otorgar permiso para usar formatos de texto menos restrictivos para crear texto enriquecido. La configuración incorrecta del formato de texto es un riesgo para la seguridad.
Seleccionando filtros. Cada formato de texto utiliza filtros que agregan, eliminan o transforman elementos
dentro del texto ingresado por el usuario. Por ejemplo, un filtro elimina las etiquetas HTML no aprobadas, mientras que otro transforma las URL en enlaces en los que se puede hacer clic. Los filtros se aplican en un orden específico. No cambian el contenido almacenado: definen cómo se procesa y se muestra.
Usando campos de texto con formatos de texto. Los campos de texto que permiten formatos de texto son aquellos con "formato" en la descripción. Estos son Texto (formatted, long, with summary), Texto (formatted) y Texto (formatted, long). No puede cambiar el tipo de campo una vez que se ha creado un campo.
Elegir un formato de texto. Al crear o editar datos en un campo que tiene formatos de texto habilitados, los
usuarios pueden seleccionar el formato debajo del campo en la lista de selección de formato de texto. Para asignar directamente los filtros a los roles se va a:
Acceder al panel de administración.
En el menú de arriba se va a People
En la sección de Permissions
Se busca en la tabla que se muestra debajo la sección de Filter
Configuración de Robots.txt
No se debe usar el robots.txt como mecanismo para bloquear el acceso a directorios de la aplicación web. Establecer rutas de directorio no permitidas divulga la ubicación de estas, convirtiéndose en una posible vulnerabilidad.
Por defecto drupal viene con un fichero robots.txt predefinido que se encuentra en la raíz del sitio [12]. Este se debe modificar y poner esto:
User-agent: *
Sitemap: http://urldelsitio/sitemap.xml
Es recomendable quitar también los comentarios, pues el robots.txt al ser un fichero de texto muestra todo el contenido cuando se accede a él desde la url.
Cambiar los prefijos de las tablas en la base de datos
Drupal por defecto no pone prefijos. Pero esto puede ser una vulnerabilidad ya que los nombres de sus tablas son conocidos, y esto permite que un atacante pueda realizar consultas SQL directas a la Base de Datos.
Existen varias vías para resolver este problema:
Modificar la configuración durante de la instalación: Durante la instalación de drupal en la parte de la base de
Modificar la configuración después de instalado: En caso de haber creado la Base de datos por defecto se debe modificar y agregar un prefijo aleatorio [16].
Para mirar más en detalle el segundo punto, se analizara como poner los prefijos en Postgres y en MySQL
POSTGRES
Los cambios se harán desde la consola. Para ello lo primero que se debe hacer es entrar a postgres mediante el siguiente comando:
sudo su - postgres
En este caso postgres es el usuario que se crea en la instalación por defecto.
Una vez que se está dentro de la consola de postgres pasamos a levantar el gestor de base de datos psql: psql
Posteriormente debemos conocer las bases de datos que existen y ver si se encuentra la que usa la aplicación web. \l basename
Ahora se conectara con la base de datos que guarda la información del sitio. \c basename
Para ver que tablas tiene la base de datos se pone: \dt
Para cambiar el nombre de las tablas y agregar el prefijo se debe poner la siguiente consulta SQL y cambiar cada una de las tablas.
ALTER TABLE users RENAME TO prefijo_users;
MYSQL
mysql -u nombre_del_usuario
Posteriormente debemos conocer las bases de datos que existen y ver si se encuentra la que usa la aplicación web. show databases;
Ahora se conectara con la base de datos que guarda la información del sitio. use basename;
Para ver que tablas tiene la base de datos se pone: show tables;
Para cambiar el nombre de las tablas y agregar el prefijo se debe poner la siguiente consulta SQL y cambiar cada una de las tablas.
RENAME TABLE users TO prefijo_users;
Después de modificar las tablas y agregar el prefijo deseado, se tiene que actualizar los datos de la base de datos en el archivo de drupal drupal/settings.php modificando el prefix.
$databases['default']['default'] = array ( 'database' =>'drupal',
'username' =>'root', 'password' =>'', 'prefix' =>'prefijo_', 'host' =>'127.0.0.1', 'port' =>'5432',
'namespace' =>'Drupal\\Core\\Database\\Driver\\pgsql', 'driver' =>'pgsql',
);
Realizar una copia de seguridad de un sitio de Drupal implica realizar una copia de seguridad tanto de la base de datos del sitio como de sus archivos [9].
Base de datos:
Según el gestor de base cambia la forma de exportar e importar. En mysql:
Para Exportar:
mysqldump -u usuario -p nombre_base_de_datos > basename.sql
Para Importar:
mysql -u root -p nombre_base_de_datos < /ruta_donde_esta/basename.sql
En postgres: Para Exportar:
pg_dump -U username -W -h host basename > basename.sql
Para Importar:
psql -U postgres -d base_de_datos -f basename.sql
otra vía:
psql -U username -W -h host basename < /ruta_donde_esta/basename.sql
Para salvar el directorio del Sitio Web:
Archivos importantes para la configuración de la aplicación donde se realizan las modificaciones del sitio.
.htaccess
web.config
site/default/settings.php
Existen dos directorios de gran importancia ya que en ellos se guardan toda la información del Sitio Web:
core/themes, en este directorio estarán los temas que usa Drupal
Prevenir la navegación por directorios
Los problemas de configuración que habilitan la navegación de los directorios y recursos de una aplicación web son tan comunes que a veces algunos administradores llegan a pensar que esto es algo normal, llegando incluso a convertirse en una forma de brindar “servicios FTP” [3].
Por este motivo es recomendable añadir un archivo index.php en blanco en los directorios internos de la instalación. Otra opción es:
Drupal trae por defecto el fichero .htaccess, el cual se encuentra en el directorio raíz. Se debe revisar el fichero para ver si existe ya en caso de que no este se debe poner al final de la manera que se muestra a continuación.
Options All -Indexes
Incorporación de encabezados de respuestas HTTP de seguridad
El protocolo HTTP tiene campos de encabezados especializados en mejorar la seguridad de las transacciones HTTP. A pesar de ello, es difícil encontrar servidores y aplicaciones web que incorporen por defecto las configuraciones necesarias para enviarlos [6]. Los campos de encabezados recomendados son:
Strict-Transport-Security: Instruye al agente de usuario para que la conexión se realice a través de HTTPS en lugar de HTTP. Es común encontrar aplicaciones web que permiten el uso de ambas conexiones, dejando en manos del usuario la responsabilidad de indicar la forma de hacerlo.
X-Frame-Options: Especifica que no se puede embeber la aplicación web en una etiqueta HTML frame. Esto garantiza en gran medida la protección ante ataques de secuestros de clic, más conocidos por su nombre en inglés de clickjacking, los cuales se utilizan mayormente para el robo de credenciales de usuarios.
X-Xss-Protection: Contribuye a evitar los ataques de tipo XSS mediante la activación del filtro relacionado que poseen los navegadores web modernos.
X-Content-Type-Options: Instruye al navegador web que no cargue las hojas de estilo ni los scripts dañinos basados en la confusión de tipos MIME.
Si no está activado el modulo se debe buscar en el directorio mods-available con el nombre headers.load
En este fichero se debe buscar si aparece el Header always set X-Content-Type-Options "nosniff" si aparece se debe poner los demás en esta posición, de lo contrario solo se debe agregar las siguientes configuraciones al final.
<IfModule mod_headers.c>
Header always append X-Frame-Options "SAMEORIGIN"
Header always add Strict-Transport-Security "max-age=157680000" Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block" </IfModule>
Restringir el acceso a la interfaz de administración
Para restringir el acceso a la interfaz de administración se debe modificar el fichero .htaccess [14]. Se copia al final del .htaccess de la raíz del sitio de drupal:
<Files ~ "admin"> Order Deny,Allow Deny from all
Allow from 127.0.0.1 192.168.0.0/16 </Files>
Forzar la utilización de HTTP (HTTPS) Seguro en los paneles de autenticación y administración
En la actualidad, es un requerimiento esencial proteger el canal de transmisión entre el agente de usuario y el servidor web, para ello se emplean protocolos de encriptación SSL/TLS combinados con HTTP (HTTPS) [7].
Dentro de los datos más sensibles a proteger en una aplicación web están las credenciales de los usuarios. Por ello, es importante forzar, si el servidor web provee HTTPS a que se emplee este protocolo en los paneles de autenticación y administración. Para hacerlo se debe redireccionar mediante .htaccess. Una vez que el servidor haya habilitado el SSL/TLS se debe modificar este fichero, es importante que sea debajo de RewriteEngine On ya que esta línea es la que habilita la regla que se pondrá a continuación:
RewriteEngine On
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [redirect=301]
Restringir Procesos
Drupal tiene una serie de procesos que pueden ser inicializados desde una URL [4]. Estos deben ser bloqueados utilizando .htaccess, para que no puedan ejecutarse desde un navegador. Los procesos que se protegerán serán "update", "install", "cron" etc. Se incluirá el siguiente bloque de código dentro del fichero htaccess.
Se adiciona el siguiente fragmento de código al final del mismo <FilesMatch "(authorize|cron|install|upgrade).php">
Order deny,allow deny from all
Allow from 127.0.0.1 </FilesMatch>
Utilización de complementos y temas más seguros
Indudablemente un aspecto que permanentemente hay que atender es evitar la introducción de código con vulnerabilidades conocidas y por tanto el uso de complementos y temas que tengan un reconocimiento en la solución de vulnerabilidades y reciban actualizaciones permanentes [11]. Por tanto, es necesario aplicar las siguientes medidas:
Utilizar complementos publicados en el repositorio original de Drupal (https://www.drupal.org)
Analizar la puntuación y los comentarios publicados de dichos complementos.
Conclusiones
Se presentaron una serie de medidas para incrementar la seguridad a bajo nivel y para la rápida recuperación en la instalación de Drupal. La gestión de estas debe ser parte indispensable y cotidiana de los administradores de este tipo de aplicación web. Las medidas propuestas han sido aplicadas y probadas en aplicaciones web publicadas en Internet, las cuales, a pesar de estar expuestas a continuas actividades de reconocimiento e intentos de explotación, han podido bloquear con éxito esas acciones. Estos controles aplicados probaron que se puede fortalecer el CMS Drupal sin necesidad de incluir algún complemento extra. Es importante decir que con solo las medidas propuestas aquí no se garantiza una seguridad total ya que para un buena protección se deberá fortalecer cada uno de los elementos que
Referencias
1. Alghofaili, R. (2018). Security Analysis of Open Source Content Management Systems Wordpress, Joomla, and Drupal (Doctoral dissertation, California State Polytechnic University, Pomona).
2. Aquino-Cruz, M., Ibarra, M., Peralta-Ascue, M., Ilasaca-Cahuata, E., & Apaza-Tarqui, A. (2018). Brute Force Attack To Exploit Vvulnerabilities of Websites with CMS Content Management System. KnE Engineering, 3(9), 14-25.
3. Cooper, J. (2018). Migrating Ariadne from Drupal to a static site.
4. Denham, B., Pears, R., & Connor, A. M. (2018). Evaluating the quality of Drupal software modules. International Journal of Software Engineering and Knowledge Engineering, 28(05), 663-700
5. Evans, R. S., & Blais, L. (2019). Great Modules in Drupal 7... and Drupal 8...?. 6. Galbreath, N., & Lackey, Z. (2018). U.S. Patent Application No. 15/890,036.
7. Housley, R. (2018). Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) (No. RFC 8418).
8. Jenner, N. (2018). Building Websites for Beginners: Introduction to WordPress, Joomla, Wix and Drupal. CreateSpace Independent Publishing Platform.
9. Lapteva, U., & Kuzyakov, O. (2018, October). Rationale for Principles of Developing Control and Protection of Web Content Using CMS Drupal. In 2018 International Multi-Conference on Industrial Engineering and Modern Technologies (FarEastCon) (pp. 1-6). IEEE.
10.Lugar de publicación: Drupal.org. https://www.drupal.org/docs/user_guide/en/index.html 11.Lugar de publicación: Drupal.org. https://www.drupal.org/project/project_module
12.Patel, S. K., & Prajapati, J. B. (2018). Joomla, Drupal and WordPress SEO Comparison. Journal of Computer Technology & Applications, 9(1), 17-23.
13.Rodriguez Sosa, A. V. (2019). An Authentication mechanism for stateless communication.
14.Shah, D., Shah, V., Busa, S., & Correia, S. (2019, April). ALLIO-All in One Multithreaded Server. In 2018 Fourth International Conference on Computing Communication Control and Automation (ICCUBEA) (pp. 1-5). IEEE.
