Buayacorp

Una de las razones para no actualizar este blog a la última versión de WordPress es que no me gusta nada el nuevo diseño del panel de administración, principalmente porque en las pruebas que hice tengo que usar mucho “scroll” para escribir entradas y precisamente no me agrada perder tiempo en ese tipo de cosas.

Bueno, desde hace algunos días quería hacer cambios para volver a la misma estructura de versiones anteriores, pero debido a mis limitados conocimientos de CSS y falta de tiempo, no hice casi nada. En fin, luego de revisar la página de reporte de bugs de este proyecto, encontré que Judy Becker se tomó el trabajo de hacer los cambios (¡gracias!) para que la estructura de “Escribir entrada” y “Escribir página” sean — a mi modo de ver — más usables (en realidad asemeja a la estructura que se tenía en versiones anteriores):

Si quieren descargar aplicar estos cambios a su versión de wordpress, pueden aplicar el siguiente parche o sobreescribir directamente los archivos que cambian — hasta donde he probado, estos cambios funcionan bien en Firefox (2.0.0.13) e Internet Explorer 7.

Por cierto, para los que todavía no actualizaron a WordPress 2.5 y quieren hacerlo, les sugiero que esperen un poco porque seguramente la siguiente versión corregirá algunos problemas de seguridad leves.

Tags: actualización, blog, Diseño, Seguridad, Wordpress

A estas alturas imagino que las pocas personas que leen este blog y que usan WordPress para sus propios blogs, seguramente ya saben que salió una nueva versión de este CMS, hablamos de WordPress 2.3.2. Entre los problemas corregidos en esta versión están:

• Mejora de rendimiento que evita que la función sanitize_post sea invocada siempre que se llame a get_post (#5325).
• Cambios en la función is_admin() para que realmente indique si el código se ejecuta en el panel de administración (/wp-admin/). (#5487).
• No mostrar los mensajes de error al hacer consultas SQL a menos que WP_DEBUG esté habilitado (#5473).
• Verificar que los datos de conexión a la base de datos sean adecuadas y mostrar mensajes de error si la instalación falla debido a permisos insuficientes (#5495).
• Soporte para páginas de error personalizadas cuando la conexión a la base de datos falla. (#5500).
• Cambios para hacer que la generación de enlaces en los contenidos de la entrada y comentarios sea más selectiva. ([6450]).
• Cambios en wp-mail.php para evitar posibles ataques XSS (#5484).
• Cambios para que no se muestren las entradas recientes a usuarios que no tienen permisos (#5535).
• Cambios para eliminar información sensitiva expuesta a través del método XMLRPC wp.getAuthors (#5534).
• Verificación de permisos en varios métodos XMLRPC ([6504]).
• Verificación de permisos en varios métodos del protocolo de publicación Atom ([6508]).
• Cambios en la función validate_file() para evitar problemas de inclusión local de ficheros en windows ([6521]).

Fuente

Aclaración

Erróneamente se me atribuye el descubrimiento de un bug relacionado a la función is_admin que permitía ver los borradores y entradas privadas. Mi participación en esta última versión tiene que ver más que todo con problemas relacionados a XMLRPC, wp-mail.php y otros que por el momento no puedo comentar, puesto que no tienen que ver mucho con la versión clásica de WordPress y además las correcciones a estos problemas probablemente recién se incluyan en la nueva versión. Aquí un extracto, ligeramente modificado para no dar ningún detalle, del intercambio de correos que tuve con uno de los desarrolladores:

By the way, we added some measures to address the problem you found. It’s on wordpress.com right now. It’s a fairly big change, and since its mainly an MU problem, we won’t address it in WP until either 2.3.3 or 2.4.
Sound good?

Finalmente, es posible que esta sea la última entrada que escriba este año antes de viajar a mi pueblo natal, pero no quiero irme sin antes agradecer a todos y cada uno de ustedes por cada visita, enlace o comentario que hayan hecho.

Les deseo un feliz y próspero 2008.

Tags: releases, Seguridad, Web, Wordpress

Muchas veces he querido habilitar la suscripción de usuarios en este blog por diferentes motivos: problemas con el spam, evitar que se muestre publicidad a lectores habituales, etc; pero todas esas veces tuve que desistir porque de un modo u otro he ido descubriendo que esta opción puede “costarme caro” si es que algún usuario malintencionado tiene algo en contra mía.

Entre los problemas que recuerdo haber reportado y que requerían del registro de usuarios activado tenemos los siguientes:

• Inyección de SQL en WordPress 2.2 a través del método wp.suggestCategories
• Usuarios sin privilegios de administrador podían realizar ciertas acciones como activación/desactivación de plugins, cambiar la apariencia del sitio, etc.
• Problemas de seguridad variados: XSS, inyección de SQL, etc.

Volviendo al tema central, este problema de seguridad del que había comentado meses atrás en el blog de David, permite que un usuario registrado obtenga la lista completa de usuarios, roles y correos electrónicos del blog o sitio afectado. El proceso para recuperar esta lista es bastante sencilla y sólo basta invocar al método wp.getAuthors a través de la interface XMLRPC:

<?php
include './class-IXR.php';

$client = new IXR_Client('http://dominio.com/xmlrpc.php');
$client->query('wp.getAuthors', 1, 'alex', '1234');

$response = $client->getResponse();

print_r($response);
?>

Luego de reportar este problema leve en wordpress.com (y por consiguiente cualquier otro sitio basado en WordPress MU), ya existe un ticket con parche incluido que pone fin a esta situación y es recomendable que actualicen aquellos sitios que tengan la suscripción de usuarios habilitada.

Tags: email, Seguridad, Web, Wordpress, xmlrpc

Desde hace dos semanas aproximadamente, cambió la forma como se almacenan las contraseñas en la versión en desarrollo de WordPress, ahora ya no se almacena el hash md5 de la contraseña en la base de datos — como se hace en muchos otros CMS, sino se usa phpass (Portable PHP password hashing framework) para esta tarea.

Por otro lado, también hubo un cambio en generación de cookies de autenticación, que en la actualidad son fácilmente generados a partir del hash de la contraseña almacenada en la base de datos. Esta nueva implementación está basado en el paper “A Secure Cookie Protocol” (pdf).

Sin duda estos cambios son importantes y de seguro reducirán la acción de ciertos problemas de seguridad que se basaban sólo en obtener el hash almacenado.

Tags: cookies, phpass, Seguridad, Wordpress

Luego de que alguien hiciera eco sobre un falso problema de inyección de SQL en WordPress 2.3.1, esta vez han publicado detalles de un bug que permite realizar este tipo de ataques en las ramas 2.2 y 2.3 (podría afectar a versiones anteriores también). Antes de pegar un grito al cielo y maldecir a los programadores de WordPress, vale aclarar que este bug sólo se puede reproducir siempre y cuando la codificación de la base de datos sea SJIS, BIG5 o GBK.

El problema radica en que en los juegos de caracteres de ancho variable mencionados, es posible que a partir de secuencias de caracteres no válidas y luego de aplicar la función addslashes, se pueda realizar ataques de inyección de SQL. Por ejemplo en la prueba de concepto del mencionado bug envían la secuencia 0xb327 (caracter multi-byte no válido en Big5) que luego de aplicarle la función addslashes la cadena resultante será 0xb35c27 (notar que el caracter \ = 0x5c se agregó antes de la comilla simple ' = 0x27), sin embargo en esta codificación la secuencia 0xb35c (許) es un caracter multi-byte válido por lo que en realidad la cadena resultante tendría la comilla simple sin escapar (許').

Dado que WordPress cambia la codificación de la conexión con SET NAMES 'GBK' (que es lo que hace cuando se especifica un valor para DB_CHARSET en el archivo de configuración), este problema de seguridad tendrá los mismos efectos aún usando la función mysql_real_escape_string.

Actualización: He subido un ejemplo que ilustra el problema descrito. El código de ese ejemplo es el siguiente por si quieren hacer pruebas:

<?php
header('Content-Type: text/plain; charset=Big5');

$login = chr(0xB3).chr(0x27) . ' UNION ALL SELECT * FROM foo /*';
if ( isset($_GET['login']) )
        $login = stripslashes($_GET['login']);

$sql = "SELECT * FROM wp_posts WHERE login = '%s'\n";

echo sprintf($sql, addslashes($login));

mysql_connect('localhost', 'tests', '1234');
mysql_query('SET NAMES Big5');

echo sprintf($sql, mysql_real_escape_string($login));

mysql_close();
?>

Lectura recomendada

• addslashes() Versus mysql_real_escape_string()
• mysql_real_escape_string() versus Prepared Statements

Tags: addslashes, multi-byte encoding, mysql_real_escape_string, Seguridad, Sql Injection, Wordpress