Auditoría de seguridad Drupal: análisis técnico para organizaciones institucionales y enterprise
Por Kike Gandia · Co-Fundador y CEO, OSCP
Drupal es el CMS elegido por administraciones públicas, universidades, medios de comunicación y organizaciones complejas que necesitan control avanzado sobre contenido, roles y flujos de publicación. Su robustez como plataforma no elimina los riesgos de seguridad: los módulos de terceros, las configuraciones custom y la complejidad del entorno son vectores de ataque que requieren análisis específico.
Drupal en organizaciones complejas: superficie de ataque específica
Una instalación Drupal enterprise típica incluye docenas de módulos contrib, desarrollos custom, integraciones con sistemas internos (LDAP, SSO, ERP), roles de usuario complejos y un entorno de hosting que puede abarcar múltiples servidores, CDN y balanceadores. Esta complejidad amplía la superficie de ataque más allá de lo que un análisis genérico puede cubrir.
Drupalgeddon (CVE-2014-3704) y Drupalgeddon2 (CVE-2018-7600) son los ejemplos más conocidos de vulnerabilidades críticas del core con impacto masivo. Pero la mayoría de compromisos actuales en Drupal se producen a través de módulos contrib desactualizados o configuraciones incorrectas.
Qué cubre una auditoría de seguridad Drupal
- Versión del core y módulos contrib frente al historial de Security Advisories del equipo de seguridad de Drupal
- Análisis de módulos custom: código PHP, hooks, formularios, acceso a base de datos y control de permisos
- Revisión del sistema de roles y permisos de Drupal: complejidad de las configuraciones y posibles escaladas
- Pruebas sobre el formulario de login y el sistema de autenticación: fuerza bruta, enumeration y bypass
- Análisis de la API REST y JSON:API de Drupal: endpoints accesibles sin autenticación y control de acceso
- Revisión de integraciones: LDAP/Active Directory, SSO (SAML, OAuth), sistemas de ficheros y almacenamiento externo
- Configuración del servidor: permisos de ficheros, acceso a directorios sensibles (/sites/default/settings.php) y cabeceras HTTP
Cumplimiento y ENS en organizaciones públicas con Drupal
Las administraciones públicas españolas y europeas que usan Drupal están sujetas al Esquema Nacional de Seguridad (ENS) o a normativas equivalentes. Una auditoría de seguridad Drupal genera la evidencia técnica de pentesting requerida para los procesos de certificación ENS y para cumplir con los controles de seguridad de aplicaciones web del estándar.
Core, contrib, código a medida y configuración: dónde está el riesgo de verdad
Hablar de "la seguridad de Drupal" en bloque lleva a invertir el esfuerzo en el sitio equivocado. Cada capa tiene un dueño distinto, un riesgo dominante distinto y una forma distinta de cubrirse.
| Capa | Quién la mantiene | Riesgo dominante | Cómo se cubre |
|---|---|---|---|
| Core de Drupal | El equipo de seguridad de Drupal | La ventana entre el advisory y vuestro despliegue | Proceso de parcheo con responsable y plazo comprometido |
| Módulos contrib | Mantenedores voluntarios, con dedicación desigual | Módulos sin mantenedor activo o directamente abandonados | Inventario con el estado de mantenimiento de cada uno |
| Módulos a medida | Vosotros o vuestro proveedor | Nunca han pasado una revisión de seguridad | Revisión de código sobre hooks, formularios y consultas |
| Configuración y permisos | Vuestro equipo | Permisos acumulados rol a rol durante años | Revisión de permisos efectivos, no de los que se creen tener |
| Integraciones (LDAP, SSO, ERP) | Compartida | Confianza implícita en una identidad externa | Pruebas de autenticación y de autorización en la frontera |
En la práctica, la capa que más hallazgos genera en organizaciones grandes no es el core —que suele estar razonablemente al día— sino la combinación de contrib abandonado y permisos de rol acumulados.
Cómo encaja con el ENS y qué evidencia queda
Para una administración pública o una entidad sujeta al Esquema Nacional de Seguridad, la auditoría no es solo un ejercicio técnico: tiene que dejar un rastro utilizable en el proceso de adecuación y ante el auditor de certificación.
Para que sirva, el informe tiene que dejar claro el alcance exacto (qué entornos, qué dominios y qué quedó fuera), las fechas de ejecución, la metodología seguida y su marco de referencia, cada hallazgo con su evidencia reproducible y su clasificación, y el plan de remediación con responsables. El re-test posterior es el que cierra el ciclo: documenta qué se corrigió y qué sigue abierto con su justificación. Conviene recordar que una auditoría técnica aporta evidencia para los controles de seguridad de aplicaciones web, pero no certifica por sí sola: la certificación la emite una entidad acreditada sobre el conjunto del sistema.
FAQ
¿La auditoría es compatible con Drupal 7, 9 y 10?
Sí, aunque Drupal 7 alcanzó el fin de soporte oficial. Si tu organización sigue en Drupal 7, la auditoría documenta el riesgo específico de la versión EOL y prioriza la migración como parte del plan de remediación.
¿La auditoría incluye la revisión de los módulos de workflow y publicación?
Sí. Los módulos de workflow, content moderation y publicación son componentes con lógica compleja de control de acceso que pueden contener escaladas de privilegios entre roles editoriales.
¿Qué entrega realmente una auditoría de un sitio Drupal?
Un informe de hallazgos priorizados, con cada problema valorado por explotabilidad e impacto de negocio, la evidencia de prueba de concepto de todo lo que sea explotable, y un plan de remediación mapeado sobre vuestro inventario de módulos contrib y a medida. No es la salida de un escáner de vulnerabilidades. Incluye además un re-test posterior a las correcciones.
¿Necesitáis acceso de administrador al sitio?
Para la parte de caja negra no hace falta nada. Para revisar permisos efectivos, roles y configuración se necesitan cuentas con los perfiles que existan —incluida una de administración— porque muchas escaladas entre roles editoriales solo se ven desde dentro. Todo se acuerda por escrito antes de empezar y se trabaja preferentemente sobre un entorno equivalente a producción.
¿Se puede hacer sobre preproducción en vez de producción?
Es lo recomendable siempre que el entorno sea realmente equivalente: mismos módulos, mismas versiones, misma configuración de roles e integraciones. La diferencia habitual está en la configuración del servidor y en las integraciones reales, así que esa parte suele verificarse de forma pasiva contra producción mientras las pruebas activas se ejecutan en preproducción.
¿Qué pasa si encontráis algo crítico a mitad de la auditoría?
Se comunica de inmediato, sin esperar al informe final. Un hallazgo que permita comprometer el sitio o acceder a datos personales se reporta en cuanto se confirma, con la información mínima para que podáis mitigarlo ese mismo día, y después se documenta con el resto. Retener un crítico hasta la entrega no tiene ninguna justificación.