Categories
Web WordPress

WordPress 3.2: ¿vale la pena actualizar?

Como todos saben, el lanzamiento de la versión estable de WordPress 3.2 está programada para el 30 de junio. Sin embargo, algunos no parecen estar muy contentos por las pocas características nuevas que incluye y generalmente, son ellos mismos quienes piden que se mejore el rendimiento. Se repite siempre el mismo fenómeno cada vez que se publica una nueva versión mayor. Sin embargo, se suele olvidar que agregar más funcionalidad y mejorar el rendimiento de una aplicación son conceptos que generalmente no van juntos de la mano.

Como dije anteriormente en otra entrada, no he seguido la evolución de esta aplicación durante los 3 últimos años. Pero por lo que comentan los desarrolladores de WordPress, esta nueva versión será un poco más rápida, aunque no especifican en qué exactamente. Imagino que el hecho de dejar de soportar PHP4 tendrá algún impacto. Aunque mirando rápidamente el historial, no parece haber muchos cambios. Sólo se borraron dos archivos php y se borraron unas cuantas funciones de wp-includes/compat.php. Lo demás, me parecen cambios cosméticos en la migración de PHP4 a PHP5, por ejemplo el cambio de los constructores (de function clase(){...} a function __construct(){...}), pero como no soy experto en PHP, no sé si haya mejoras de rendimiento al hacer eso.

Dicho todo esto, esta nueva versión, al igual que la última versión menor, también vendrá con correcciones a problemas de seguridad, algunos de los cuales afectan también a varias versiones anteriores. Pero tampoco es para poner el grito en el cielo, es más probable que no sea de gravedad para blogs como éste. No lo digo porque sea yo quien lo corrigió, sino porque sólo hay dos cuentas activas en este blog. Si pasa algo, sé a quien echarle la culpa 😀 .

Categories
Seguridad WordPress

Seguridad: validación de datos

No sé si todavía haya alguien que suela darle una mirada a los artículos de este blog, más aún si es alguien que conocía este sitio cuando solía escribir desvariar sobre temas relacionados a la seguridad hace unos años atrás. No sé si he escrito sobre este tema antes, pareciera ser que no tengo muy buena memoria.

Otra vez tomo como ejemplo WordPress*. Por malas decisiones que se hicieron desde el principio (por ejemplo imitar las "magic quotes"), hay muchas vulnerabilidades que hubieran podido evitarse. El problema es que muchas de las validaciones que se hacen sobre los datos enviados por el usuario, se hacen desgraciadamente casi al principio. En un mundo ideal, esto no debería causar ningún problema. Sin embargo, en la práctica hacer este tipo de cosas asegura que a medida que las aplicaciones van evolucionando, aparecerán los problemas. Muchas de estas restricciones pueden ser sobrepasadas utilizando escenarios no previstos. Luego de la publicación de la versión 3.2, que corregirá también problemas de seguridad relativamente graves, iré comentando más a detalle los problemas encontrados.

Aún cuando algunos desarroladores como Mark Jaquith recomiendan que se debe escapar lo más tarde posible (escape late), lamentablemente en este momento es algo difícil de hacer cuando la existen una gran cantidad de plugins y temas que utilizan estas "protecciones".

La lección a retener es que es mejor escapar o validar los datos justo antes de guardarlos o realizar ciertas acciones, y justo antes de enviar el contenido al navegador.

*: Como había mencionado antes, decidí colaborar en la medida de lo posible a WordPress. Actualmente estoy algo alejado de la programación, entonces seguramente habrán más posts usando WordPress como ejemplo.

Categories
Artí­culos Seguridad Web

Collège de France: interesantes presentaciones sobre seguridad informática

Durante los meses de marzo, abril y mayo de este año, se han realizado un conjunto de presentaciones sobre seguridad (inglés, francés) en el Collège de France, en París. Pueden descargar las transparencias y ver los videos de las presentaciones.

Algunas de las presentaciones se hicieron en francés, pero felizmente casi la mayoría de las presentaciones tienen traducción en inglés (todas las que aparecen en esta entrada).

Categories
Seguridad WordPress

WordPress < 3.1.3: Multiples vulnerabilidades

Aunque en el anuncio oficial no se mencione muy claramente, esta versión trae importantes cambios.

  • La vulnerabilidad SA44409 fue corregida por el changeset 18014. Esto autorizaba a subir archivos que permitían la ejecución de código php, siempre y cuando la configuración de Apache permita aceptar múltiples extensiones. Esto es una variante de un falla anterior.
  • El changeset 18018 corrige uno de los varios problemas que reporté, en principio permitía al igual que el anterior, la ejecución de código php, con la diferencia de que no es necesario ningún tipo de configuración en especial. Tal vez dentro de un tiempo llegue a publicar el exploit que hice. También corrige fallas que permitían realizar ataques XSS.
  • El changeset 18019 corrige problemas que permiten realizar ataques XSS.
  • El changeset 18023 está relacionado con un problema relacionado a la privacidad de los backups de wordpress.

Más adelante probablemente vaya comentando más en detalle los cambios realizados y una que otra mejora que se introdujo luego de una serie de discusiones.

Categories
Seguridad WordPress

WordPress: protección contra ataques CSRF

Para aquellos que desconocen, WordPress utiliza (desde la versión 2 si mal no recuerdo) las funciones wp_create_nonce y wp_verify_nonce como sistema de protección para ataques de tipo CSRF. Más allá de algunos problemas no relacionados con la implementación de estas funciones, ha funcionado bastante bien a lo largo del tiempo.

Entrando un poco más en detalle sobre esta funcionalidad, lo que parecería que se usa es algo que se conoce como nonce en el mundo de la seguridad informática. Un nonce viene de la abreviación en inglés number used once, un número pseudo-aleatorio que normalmente se usa para evitar ataques de repetición (mala traducción para replay attacks) cuando se definen y verifican protocolos criptográficos. Volviendo al principio, lo que se usa en WordPress no son estrictamente nonces puesto que estos valores tienen una duración de 24 horas más o menos y que naturalmente puede ser usado para realizar las mismas acciones múltiples veces.

En circunstancias normales, si ese valor generado es seguro y un atacante no tiene la posibilidad de generarlo o interceptarlo, pues todavía es en cierta forma aceptable. El protocolo de manera simplificada es el siguiente.

WP  -> B  : nonce( time.action.user_id )
B   -> WP : pair( nonce( time.action.user_id ), action )

WP representa a WordPress, que envía al navegador B un valor encriptado conteniendo el timestamp, la acción relacionada y el identificador del usuario. Por su lado el navegador debe enviar el valor generado por WP y la acción que desea realizar. WP al recibir el mensaje comprueba que el numero enviado por B no ha sido modificado y corresponde exactamente a la acción a realizar. Sin embargo, una vez más, esto no se cumple siempre debido a que el valor que puede tomar action, puede ser modificado por B. ¿Las consecuencias? pues simplemente que este mecanismo puede actualmente ser evadido bajo ciertas condiciones. En el caso de un blog, puede que no sea importante, pero para otro tipo de aplicaciones hay que tener bastante más cuidado.