WPVulnerability: por qué WordPress necesita una base de datos de vulnerabilidades.

Era abril de 2022 cuando comencé a plantearme si la información de vulnerabilidades de WordPress no se estaba privatizando.

Sí, los CVE publican la información, pero no de una forma sencilla, ya que solo con esos datos no puedes realmente automatizar el saber si tu WordPress es vulnerable o no.

WordPress es seguro

Pero demos un paso atrás. ¿Es WordPress seguro? La respuesta es que sí, aunque con peros.

El núcleo de WordPress es uno de los software de código abierto más seguros del mundo, sobre todo porque hay muchos ojos encima revisando que todo funcione correctamente. Donde realmente podemos ver más problema es en los plugins y temas, sobre todo en los primeros.

Los plugins

Con alrededor de 60.000 en el repositorio oficial, más los miles más repartidos por Internet, la seguridad depende de sus desarrolladores. WordPress pone muchas herramientas en el núcleo para que se pueda crear un plugin seguro, pero, hay que hacerlo. Y en general, los desarrolladores no lo hacen.

Tanto los propios desarrolladores como empresas de seguridad van revisando la calidad de los plugins, y en ocasiones aparecen vulnerabilidades. Hasta aquí, lo normal. Esas vulnerabilidades tienen habitualmente de plazo unos 3 meses para ser corregidas y posteriormente anunciadas de forma pública. Si un desarrollador no la corrige, se produce un factor problemático: una vulnerabilidad anunciada, sin parche y que puede afectar a miles de sitios.

Mi sitio es vulnerable

Pues, en realidad, no lo puedes saber porque WordPress no te lo indica. Hasta ese momento podías utilizar plugins freemium o premium que suelen incorporar un cortafuegos en el que se te indicaba que podría haber alguna vulnerabilidad y te invitaban a actualizar, o lo hacían automáticamente, sin tener en cuenta tu opinión.

Otras herramientas mandan toda la información de tu sitio a sus servidores y allí es donde te avisan. Una falta de privacidad y un perfilado de usuarios en toda regla cuando tienes varios WordPress.

Una base de datos para todo

Un primer paso del proyecto, y la matriz de todo, fue crear una API en la que estén todas las vulnerabilidades. Una base de datos a la que cualquiera pueda acceder, con datos mínimos. La idea no era la de sustituir a otros proyectos que dedican su negocio a esto, sino tener un sistema muy básico que permita a los usuarios de WordPress a estar alerta.

Eso llevó al lanzamiento de la WordPress Vulnerability Database API con un lema muy simple: Democratizing WordPress security information (democratizando la información de seguridad de WordPress).

La primera versión incluía poco más de 4.000 vulnerabilidades, lo que permitía salir en beta.

Un plugin que no sepa nada de tu sitio

El siguiente paso lógico era, que sí teníamos una base de datos con información, desde tu propio WordPress se pudiera consultar y visualizar los posibles problemas de seguridad. Sin más intención.

Esto llevó a que al entrar en la lista de plugins se pudieran ver mensajes con un aviso que te dijera si tenías algo con vulnerabilidades. La solución en la mayoría de casos era actualizar. Si no había actualización, la recomendación era sustituir el plugin por otro de las mismas funcionalidades.

La información de las vulnerabilidades se almacena en local, de forma que el proyecto no sabe nada sobre quién hace la petición, ya que todo se anonimiza en la CDN, sin saber ni siquiera la IP desde la que se hace la petición.

Añadir todas las vulnerabilidades

Durante un año el proyecto se centró en mejorar la calidad de la información, las fuentes de datos y tener una información lo más exacta posible.

Esto implicó añadir fuentes de datos diversas y comenzar un proyecto de duplicidad de las vulnerabilidades (algo sobre lo que se sigue trabajando).

Todas las vulnerabilidades históricas del propio núcleo de WordPress y, hasta la fecha, casi 9.000 plugins (con 28.000 vulnerabilidades) y caso 1.000 temas (con 2.000 vulnerabilidades) forman parte de la base de datos.

Mejorando el plugin

En las siguientes versiones del plugin se añadieron mejoras varias: poder ver las vulnerabilidades en el Salud del Sitio, envío de un correo con las vulnerabilidades, un refactoring (reprogramación completa) del plugin para hacerlo óptimo, compatibilidad desde WordPress 4.1 hasta la última versión, que también implica dar soporte a todas las versiones de PHP soportadas por cada versión, el lanzamiento de comandos WP-CLI…

Otro foco fue la incorporación de procesos que revisaban la calidad y seguridad del código. Esto incluye los WordPress Coding Standard, además de herramientas externas que analizan la seguridad del código. En las últimas versiones, se ha incluido la revisión con el Plugin Check (PCP), la herramienta del Equipo de Plugins para validar algunos elementos de compatibilidad.

Pero no solo eso. La optimización, caché de los datos y otros elementos se incluyeron para por ejemplo no afectar en nada al frontal, y que en el panel de control solo se cargue el plugin cuando realmente el usuario tiene acceso a los datos.

Incluso, se planteó el soporte a WordPress MultiSite (que no es sencillo) y una nueva columna en los plugins que indican si el plugin está cerrado, o la fecha de su última actualización.

La seguridad no es solo WordPress

Mucha gente puede pensar que teniendo todos los elementos de WordPress al día es más que suficiente, pero no es así. WordPress necesita de distintos elementos, como PHP, un servidor web, una base de datos… por eso los últimos avances han ido en ese sentido: incorporar vulnerabilidades de versiones de PHP, Apache HTTPD, nginx, y en un futuro de MySQL o MariaDB.

Tener un hosting inseguro hace que tu WordPress también lo sea, aunque tengas todo al día.

Descargando el plugin

El plugin es “instalar y listo”. Si quieres, puedes configurarte que envíe los correos, pero eso ya es tu decisión.

Proyecto colaborativo

Cuando comencé el proyecto tenía en mente un sistema híbrido de participación. Sabía que el control de la base de datos no podía ser completamente abierto, aunque los datos y la API sí que lo son, y por serlo, no requiere ni una clave de API.

Lo que sí tenía que ser 100% abierto era el plugin. Saber qué necesitan los usuarios, escucharlos, ha sido clave para mejorar el plugin, como para corregir problemas que se han ido encontrando y que han sido gracias a los reportes de usuarios que lo utilizan.

Seguro por defecto, lo dice la ley

Hace poco que se aprobó la Ley de Ciberresiliencia, una legislación a nivel europeo que obliga a todos los implicados en el desarrollo del software a ser parte de la solución.

Entre otras cosas va a obligar a que aquellos que gestionan un sitio WordPress sean responsables de su seguridad, por lo que si eres alguien que desarrolla plugins o temas, si eres una agencia que crea sitios para otras personas o empresas, o si simplemente gestionas un WordPress, la ley está ahí y te obliga a mantener tu sitio seguro.

Así que, si quieres ser parte de esa solución: mantén tu WordPress seguro.

Fuente:
Javier Casares
javiercasares.com