Inicio / Blog / CMS - Cómo gestionar los plugins de forma segura (y no morir en el intento)

CMS - Cómo gestionar los plugins de forma segura (y no morir en el intento)

Publicado el 25/04/2013, por Antonio Sanz

Hoy en día es imposible negar la importancia en Internet de los CMS (Content Management Systems, Sistemas Gestores de Contenidos). Software como Wordpress (con más de 64 millones de blogs instalados), Drupal o Joomla, nos permiten crear sitios web complejos de forma sencilla con la instalación por defecto.

Estos CMS tienen la posibilidad de ser ampliados con multitud de características mediante plugins (si usamos la terminología de Wordpress, se denominan módulos en Drupal o componentes en Joomla).  La instalación de estos plugins es muy sencilla, no requiriendo en muchos casos más de un par de clicks. También es necesario tener en cuenta los themes (que permiten cambiar el aspecto de nuestro CMS), que aunque estando orientados a cuestiones de aspecto gráfico cada vez incluyen más programación, estando sujetos a los mismos problemas que los plugins.

El problema derivado del uso (y abuso) de los plugins tiene varias derivadas relativas con la seguridad: Por un lado tenemos la sencillez de su instalación, que anima en gran medida a la instalación “por probar” y sin pensar detenidamente qué hace exactamente ese plugin. Y por otra parte tenemos la sencillez de desarrollo de estos plugins, que hace que casi cualquiera pueda crearlos (con diferentes niveles de calidad, sobre todo en lo relativo al desarrollo seguro de software).

La otra pata derivada es la actualización de estos plugins, sobre todo en lo referente a posibles fallos de seguridad. Si sumamos todas estas variables, no es de extrañar que tengamos verdaderos fiascos de seguridad como el de TimThumb o Uploadify en Wordpress, por lo que podemos afirmar que es necesaria una estrategia de gestión de estos plugins. Si nos basamos laxamente en ITIL, el ciclo de vida de un plugin podría ser el siguiente: necesidad, búsqueda, implantación, operación y obsolescencia.

En primer lugar surge la necesidad de disponer de una característica que no viene implementada por defecto (por ejemplo, el crear automáticamente un tweet por cada entrada en nuestro blog Wordpress). Las primeras preguntas serían: ¿de verdad necesito esta funcionalidad?. ¿Estoy dispuesto a aceptar el trabajo adicional que supone el buscar un plugin adecuado, instalarlo y gestionarlo?.

Si la respuesta es afirmativa, pasaremos a la fase de búsqueda, en la que debemos elegir entre los plugins disponibles aquel que mejor se ajuste a nuestras necesidades. Elegir correctamente en esta fase nos puede ahorrar muchos quebraderos de cabeza futuros, así que deberíamos observar los siguientes puntos:

  • Compatibilidad: ¿Garantiza el plugin ser compatible 100% con nuestra versión del CMS?. Una diferencia entre versiones puede suponernos un serio disgusto.
  • Madurez del código: Un código maduro debería de tener menos fallos de seguridad y ser en general más robusto. Esta madurez se puede observar a partir de las versiones, la antigüedad del plugin y de la información que nos faciliten los changelogs (sobre todo en cómo han respondido a fallos de seguridad).
  • Credibilidad del autor: La documentación y el soporte ofrecidos por el autor del plugin nos pueden dar mucha información acerca de la calidad del mismo.
  • Puntuación, opiniones y número de descargas: Un software con un número elevado de descargas y opiniones positivas siempre tendrá algo más a favor (cuidado con las puntuaciones altas con pocas descargas ya que pueden ser intentos de “inflar” la calidad del plugin).

Una vez elegido uno o varios candidatos que satisfagan nuestras necesidades, se pasa a la fase de pruebas (que a ser posible no debería de realizarse en un sistema en producción), en la que se verifica que el plugin es adecuado. 

Llegados a este punto, si el CMS cumple con una función crítica, no estaría de más realizar un análisis estático del plugin empleando herramientas como RIPS, para asegurarnos de que el plugin está limpio de XSS, inyecciones SQL u otros “regalos”.

Una vez seguros de que el plugin es operativo, pasamos a la fase de implantación en producción, en la que sería necesario observar que el plugin interactúa correctamente con el resto de componentes del sistema. Será también necesaria la integración con los sistemas de seguridad existentes (por ejemplo, mod_security en modo estricto interfiere con muchos plugins de Wordpress).

La operación de un plugin tiene un aspecto fundamental: la actualización del mismo. El enfoque tradicional de sistemas de la gestión de parches de seguridad sigue más o menos los siguientes pasos: detección del fallo de seguridad, mitigación inicial, evaluación del parche, prueba en preproducción, evaluación de fallos, copia de seguridad, instalación en producción y seguimiento del mismo.

Este enfoque es consistente y sensato desde el punto de vista de la seguridad, pero tiene el inconveniente de que pueden transcurrir varios días hasta que el parche está finalmente operativo. Y en sistemas tan expuestos a Internet, los plazos para remediar el fallo de seguridad se puede reducir a meras horas, por lo que esta estrategia nos expone a un mayor riesgo.

Se propone entonces tender hacia la actualización automática, haciendo que nuestros CMS (y por ende, todas las extensiones instaladas) instalen las actualizaciones periódicamente y sin interacción por parte del usuario. Por ejemplo, Wordpress tiene el plugin Automatic Updater, y en Drupal podemos hacer uso de drush (el comando drush -r /path/de/drupal -y --security-only pm-update en el cron nos actualizará el sistema instalando solo los parches de seguridad).

Este enfoque tiene un riesgo obvio: la pérdida de control sobre las actualizaciones y sus riesgos inherentes (por ejemplo, que una nueva versión de un plugin rompa nuestro sitio web). La mejor forma de implantar estas actualizaciones automáticas es mediante una estrategia completa de copias de seguridad, que nos permita recuperar el sistema en todo momento.  

Entre la elección de sufrir un fallo del sitio o una intrusión, la primera opción siempre parece el mal menor (los tiempos de recuperación con backups y la posible pérdida de imagen se reducen sensiblemente).  Sin embargo, queda dentro de cada cual elegir la estrategia que mejor se adapte a su cultura empresarial y le permita minimizar los riesgos que se asumen.

La fase final del ciclo de vida de un plugin es la obsolescencia. Los plugins más famosos suelen ser aquellos que ofrecen las funcionalidades más atractivas, algo que los desarrolladores de los CMS suelen detectar e implementar en versiones posteriores, lo que permite eliminar el plugin. Es importante el mantener una política de gestión de estos plugin que los permita deshabilitar en primera instancia y luego eliminarlos del sistema una vez no sean necesarios.

Es necesario indicar que la seguridad de los CMS no se limita a la gestión de los plugins. Aspectos como gestión de contraseñas, permisos o limitación de los accesos  entre otros son fundamentales y deberían de ser tomados muy en cuenta para diseñar una estrategia de seguridad de todo el CMS (basándose por ejemplo  en las guías de seguridad en Wordpress y en Joomla! desarrolladas por el INTECO-CERT).

En conclusión, los plugin nos permiten ampliar un CMS y hacerlo mucho más potente y flexible… pero hay que ser conscientes de los riesgos que su uso implica y diseñar una estrategia que nos permite su mitigación.

Etiquetas: