(In)seguridad en WordPress, por Stefan Esser

Dado que opiniones hay tantas como sujetos, y la mía es sólo otra más (basada -eso sí- en mi experiencia como usuario de diversos sistemas de publicación de contenidos web durante varios años), hoy traigo a portada la opinión sobre WordPress de Stefan Esser, reconocido experto mundial en seguridad de PHP, responsable de PHP Security Blog, creador del Mes de los bugs de PHP, autor de la primera ruptura del DRM de la Xbox mediante software, miembro fundador del equipo de respuesta de seguridad de PHP.net, auditor de aplicaciones PHP, etc, etc.

Una reciente entrevista, realizada a Stefan Esser por David Kierznowski para BlogSecurity, nos permitirá conocer qué opina un experto mundial de este nivel sobre WordPress. La entrevista es larga, y no quería traducirlo todo, pero al final...

Dice Esser:

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.

Para aquellos lectores de Kriptópolis que me piden opinión sobre qué software es el mejor (o el más seguro, o el más apropiado), no tengo una respuesta universal. Para Kriptópolis estoy encantado con Drupal, pero tampoco se lo recomendaría a todo el mundo. Drupal necesita mucha máquina (sobre todo mucha RAM) a poco que se disparen las visitas o se haga uso de ciertos módulos, por lo que resulta muy poco aconsejable si el blog tiene cierta popularidad y no se dispone de un servidor dedicado (muchos conocéis de sobra mis pasadas dificultades por estos motivos). A cambio, es un software muy bien escrito y muy depurado en cuanto a seguridad. Los fallos son escasos, y generalmente más ligados a módulos extra que al propio código base. Su sólido sistema de filtrado de entradas (y salidas) y su interfaz con la base de datos son poco proclives a disgustos. Su sistema de registro ayuda a detectar cualquier intento de ataque. Hace años utilicé pMachine (ahora reemplazado por ExpressionEngine), que al menos en aquella época me pareció un software muy bien escrito, nada proclive a fallos y con un gran servicio detrás.

• Interview with Stefan Esser [BlogSecurity].