Mi equipo y yo en nvisionative nunca hemos estado vinculados a ningún CMS en particular. Siempre he dicho que nuestro negocio no depende de DNN. Me doy cuenta de que esto puede sorprender a algunos miembros de la comunidad DNN, pero es así. En vez de forzar a todos en torno a determinado conjunto de herramientas, nos enfocamos en crear soluciones sólidas para nuestros clientes. Para eso, mantenemos la mente abierta y usamos la herramienta adecuada para cada trabajo. Dicho esto, cuando tiene sentido, por supuesto elegimos DNN. Sin embargo, hay momentos en los que no tenemos opción de elegir y estamos obligados a usar herramientas impuestas por nuestro cliente o heredadas de una implementación ya existente. Y he aquí que, a veces (más veces de lo que nos gustaría admitir) esas herramientas incluyen WordPress.
La historia
Para aquellos que no lo sepan, WordPress se construyó inicialmente como un sistema de publicación personal (blog) y en realidad se construyó sobre, y como el sucesor oficial de, b2/cafelog. Se eligió PHP y MySQL como base tecnológica, con Licencia Pública General (GPL), que lo hacía bastante atractivo para las masas. Ha ganado una gran popularidad a lo largo de los años y se ha convertido en un Sistema de Gestión de Contenidos (CMS), aunque todavía muchos discuten si merece o no la denominación de "CMS". No obstante, de acuerdo con W3Techs, WordPress mueve el 60% de todos los sitios web con CMS conocido, y el 30.9% de todos los sitios web.
La elección
A cualquiera que preguntes en el Mundo WordPress, te dirá, “¡es fácil, es gratis, y hay una extensión o complemento para cualquier cosa que quieras hacer! ¿Por qué no usarlo?”
La preocupación
Lo que no le dirán es qué, tal vez, ellos no sepan por qué. Aquí radica la parte aterradora y el motivo real de por qué somos MUY CUIDADOSOS al tratar con las implementaciones de WordPress.
La intención de este blog no es ser una lista exhaustiva de todas las cosas de las que hay que estar pendientes (porque esa lista es bastante extensa). Sin embargo, nos damos cuenta de que muchos en la comunidad DNN pueden haber escuchado, o incluso usado, el argumento de la seguridad total al evaluar DNN frente a WordPress. ¿Debemos aceptar ese argumento cuando preparamos un proyecto para nuestros clientes o para nosotros mismos? ¿Confiamos en WordPress a ciegas? ¡Yo creo que no! Por lo tanto, expondré solo una vulnerabilidad de seguridad que, por sí sola, debería ser suficiente para ayudarnos a tomar una decisión informada.
Los detalles
En las versiones más recientes de WordPress, hay una REST API. A primera vista, ¡es una gran cosa! Nos permite mejorar la experiencia general del usuario mediante la creación de funcionalidades rápidas del lado del cliente, mediante complementos que pueden realizar llamadas API para acceder a datos del lado del servidor, sin tener que depender de accesos PHP más lentos para ese acceso a los datos del servidor.
También podemos usar la REST API para integrar aplicaciones de terceros (p.ej., otras aplicaciones web, apps móviles) que accedan a datos como artículos, categorías, etiquetas, multimedia y mucho másmore. Algunas acciones de la API requieren autenticación. Por ejemplo, crear, actualizat o borrar un artículo. La autenticación por cookie es el único mecanismo disponible de forma nativa en WordPress, pero se pueden añadir complementos (plugins) para proporcionar otros métodos de autentificación como OAuth y JSON Web Tokens (JWT). Se requiere un complemento de autentificación para solicitudes autentificadas desde fuera de la administración de WordPress, de temas, o de complementos.
No obstante, la mayoría de las solicitudes GET (sólo-lectura) se pueden efectuar anónimamente. Esto hace que el acceso a la mayor parte de los datos sea extremadamente fácil. Así, si quieres ver los datos, ¡ni siquiera tienes que escribir una sola línea de código!
La REST API de WordPress usa un formato como el siguiente para sus terminales (endpoints: URL de métodos que realizan determinada función):
https://example.com/wp-json/wp/v2/<object_method>
Estos terminales están pensados para ser usados en un contexto de programación, desde el código. Sin embargo, para ver cualquier información proporcionada por un terminal, sin escribir ni una línea de código, puedes acceder a la URL en cualquier navegador web moderno y podrás obtener una respuesta JSON. Bien, ¿listos para la parte más terrorífica?
Los detalles aterradores
Primero, quiero dejar claro que esto no afecta a todos los sitios WordPress. Depende de la versión de WordPress que se use y de si se han tomado o no medidas para evitar esta vulnerabilidad, bien mediante código propio, complementos o medios por parte del proveedor de alojamiento. Dicho lo cual, una implementación estándar de WordPress 4.7 expondrá una lista de todos los USUARIOS a través de un acceso anónimo, incluyendo nombre y apellidos de cada usuario, nombres de usuario, enlaces Gravatar y otros metadatos asociados. Os mostramos a continuación un ejemplo, proviniente de un destacado sitio web de noticias tencológicas. Por seguridad, hemos ocultado los datos sensibles.
Esta información puede ser mostrada y enunciada tanto a humanos como a BOTs para recolectar información confidencial. Con esta información a mano, se pueden realizar ataques de fuerza bruta contra el sitio web para obtener acceso no autorizado. ¿Y todavía hay quien se pregunta por qué tantos sitios de WordPress son pirateados?
La respuesta
¿Qué tiene que decir el equipo de la REST API de WordPress sobre esto? Bien, agárrense que vienen curvas... ahí va...
"Los nombres de usuario ya están expuestos a través de temas, fuentes RSS, etc., y esto no lo consideramos un problema de seguridad. Puede instalar un complemento de terceros si desea limitar el acceso a estos datos."
(Ref: https://github.com/WP-API/WP-API/issues/2961)
La alternativa
Todos sabemos que DNN (DotNetNuke) no ha salido indemne a lo largo de los años de las vulnerabilidades de seguridad. Sin embargo, presente en la comunidad desde el día 1, todavía puedo contar la cantidad de vulnerabilidades de seguridad sustanciales con una sola mano. ¡Eso ya es decir algo! E incluso en aquellos momentos, las vulnerabilidades se abordaron de manera oportuna y sensible, y no fueron tan serias y ni obvias como esta vulnerabilidad de WordPress (que TODAVÍA está en su documentación a la fecha de la redacción de este blog) .
Si este nivel de vulnerabilidad de seguridad (una característica, no obstante) se puede publicar así, deberíamos poner en duda CADA actualización a lo largo del tiempo y especialmente en el futuro. Ahora que se están imponiendo regulaciones más estrictas, como GDPR, nuestros negocios en su conjunto son más vulnerables que nunca. Conozco a algunos consultores de CMS que van tan lejos como para decirles a los clientes que ni siquiera tocarán los sitios de WordPress debido al nivel de riesgo que representa para sus propias compañías.
La redención
Por un momento, supongamos que tiene uno o más sitios de WordPress, está leyendo este blog y ahora le preocupa qué hacer. Ha invertido mucho para que su sitio de WordPress sea excelente, pero ahora le preocupa que sea vulnerable. Las malas noticias es que probablemente debería estar preocupado. La buena noticia es que podemos ayudarle para moverse a un CMS más seguro (como DNN) o, en el peor de los escenarios, hacer más seguro su(s) sitio(s) WordPress.
La conclusión
Espero que tener un ejemplo concreto le ayude a tomar decisiones de peso por usted mismo, su empresa y sus clientes. ¡Afuera con primero la responsabilidad y dentro con primero la seguridad!
NOTA: Este artículo es una traducción del original de David Poindexter.