Stefan Esser es un experto en seguridad PHP el cual tiene una larga trayectoria y experiencia en PHP y en su seguridad. Durante una entrevista, le preguntaron acerca de seguridad en WordPress y realmente lo que dijo me dejo marcado…
Creo que WordPress es el mejor software para blog desde una perspectiva de usuario. Su interfaz gráfico está lleno de características y adornos que no existen en otro software. Pero si me pongo mi sombrero de seguridad y me meto en el código veo varias decisiones de mal diseño. Empieza por cómo interacciona con la base de datos. Además, considero algunas de sus características bastante peligrosas. Personalmente no me gusta que el software anime a sus usuarios a tener ficheros escribibles en el directorio raíz. La característica de WordPress de editar ficheros y plantillas en el servidor hace exactamente eso. El problema es que si me apodero de la cuenta de administrador de un blog en WordPress, nada me impide ejecutar cualquier código PHP en el sistema. Y desde ahí sólo queda un pequeño paso para controlar el servidor completo.
He sido crítico con el equipo de desarrollo de WordPress porque hizo varias cosas que no están bien. Cuando has arreglado una ejecución directa de código remoto en tu rama de desarrollo y existe ya un exploit públicamente disponible, no se puede esperar varios días para publicar la actualización. Y es totalmente inaceptable que un fabricante intente rebajar la seriedad de la vulnerabilidad con afirmaciones como: “Hemos hablado con expertos en seguridad PHP y dicen que no es una vulnerabilidad seria porque requiere que register_globals esté activado.” En primer lugar, la mayoría de los servidores aún tienen activado register_globals y, además, el propio servidor de wordpress.org lo tenía activado también.
Cuando por fin sacaron la actualización, les dije que su arreglo no servía porque bastaba modificar un poco el exploit para que éste funcionara. Su reacción fue ocultar el hecho cambiando sin decir nada el fichero de descarga. No incrementaron el número de versión, sólo arreglaron el código vulnerable horas después de haberlo publicado. Y luego afirmaron públicamente que el fichero anterior estuvo on-line “brevemente”, cuando los sellos de tiempo en su interior demostraban que “brevemente” fueron varias horas.
Personalmente opino que en lo relativo a actualizaciones de seguridad, un productor de software ha de decir la verdad y asegurarse de que la gente comprende la amenaza. Los errores ocurren y también los fallos mal reparados, pero es mucho más profesional admitir que un parche no era perfecto que cambiarlo sin decir nada.
Si no recuerdo mal, la gente de phpBB en un momento dado utilizó el dinero recolectado para pagar a una empresa de seguridad que auditara el software. Estoy bastante seguro de que todavía existen varias vulnerabilidades en WordPress. Sugiero firmemente que la gente de WordPress haga lo mismo. Las auditorías gratuitas que obtienen a partir de la gente que publica fallos no cubren todo el código básico. Y quizás deberían empezar a pensar en una completa reescritura que utilice otra arquitectura. Cuando pienso en la forma en que WordPress intenta frenar la inyección de SQL, que es básicamente mediante un magic_quotes_gpc hecho en casa, me entran escalofríos. Con otra arquitectura se podrían asegurar desde el principio de que cosas como CSRF o incluso XSS no pudieran darse.
WordPress es un software para usuarios finales con poco o ningún conocimiento técnico. Por supuesto hay también administradores y desarrolladores que lo utilizan, pero la mayoría de usuarios de WordPress no leen listas de correo sobre seguridad. Normalmente no se enterarán de todos los fallos de seguridad que se encuentren. Y estoy seguro de que la mayoría de ellos simplemente actualizarán si se enteran y no pensarán más en ello. La mayoría no se ocupan de estas vulnerabilidades hasta que sus blogs son jaqueados, e incluso entonces, simplemente reinstalan y empiezan de nuevo. Dicho eso, creo que los agujeros de seguridad en WordPress podrían espantar a los desarrolladores y administradores, pero la mayoría de usuarios seguirán utilizándolo.
No conozco demasiadas alternativas a WordPress. Para mí está Serendipity/S9Y. En mi opinión la calidad del código de Serendipity es mejor que la de WordPress, pero Serendipity no es tan amistoso para el usuario. A causa de que su código básico es más pequeño, es más fácil de auditar y por tanto deja un mejor sabor de estómago. Además conozco personalmente a muchos de sus autores.
Gracias Kriptópolis (Entrevista traducida por ellos)
