DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.


¿Qué ocurre cuando un sistema para escribir blogs quiere hacerse mayor?

The Devil Is In The Details - WordPress

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.

Sample User

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.

Comments

There are currently no comments, be the first to post one.

Comment Form

Only registered users may post comments.

NewsArchives


Aderson Oliveira (18)
Alec Whittington (11)
Alex Shirley (10)
Andrew Hoefling (2)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (35)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (212)
Chris Paterra (55)
Clinton Patterson (72)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (165)
Daniel Valadas (1)
Dave Buckner (2)
David Poindexter (9)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (77)
Francisco Perez Andres (6)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (31)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (169)
William Severance (5)

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  

What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out