XSS en algunos temas de WordPress

Hace un par de días un compañero de trabajo me avisaba de que la web de Mosaic, en la que hago «más o menos» de responsable técnico tenía un problema de XSS (inyección de código) en el formulario de búsqueda.

Alarmado, rápidamente actualicé la versión de WordPress a la 2.9.1, pero no conseguí solucionar el problema. La prueba era fácil, poniendo este sencillo script en el formulario de búsqueda

<script>alert("hola");</script>

Se abría un cuadro de diálogo de alerta.

Hoy, con tranquilidad, me he dedicado a investigar. El error se produce sólo en algunos blogs de WordPress, no en todos. Por tanto no es un problema del gestor de contenidos.

Después de algunas pruebas y algunos cambios, el error ha aparecido. Es un problema de algunos temas de WordPress y es muy fácil de arreglar. En el formulario de búsqueda de los temas que tienen la vulnerabilidad podemos ver algo parecido a esto:

<label for="s"><input type="text" name="s" id="s" size="50" maxlength="200" value="<?php echo get_search_query(); ?>" /></label>

El problema es el echo del código php. Eliminándolo se elimina el problema. Fácil :)

Actualización: Tal como apuntan Javier y Oscar en los comentarios, el problema no es tanto del echo (que permite mostrar la cadena buscada) como el hecho que no se filtre adecuadamente get_search_query().

Por tanto, tal y como propone Javier, en vez de eliminar el echo la solución más elegante es <?php echo htmlentities(get_search_query()); ?>

Mis problemas con WordPress

Lo apunto aquí por si puede ser de alguna utilidad para alguien.

En los últimos tiempos he visto hackeados mis dos blogs creados con WordPress (Badalona bitàcola y Desnivell) cada uno de una manera diferente.

En Badalona bitàcola el ataque consistió en redireccionar al bot de Google a una página basura con cientos de enlaces. El resultado fue que mi página cayó de los índices de Google de una manera espectacular. Lógico, cuando Google llegaba no encontraba mi página, sino otra diferente :( Me di cuenta porque usando la herramienta para webmasters de Google no conseguía verificar la página.

¿Cómo lo solucioné? El problema estaba en el fichero .htaccess Lo malo es que lo tuve que revisar varias veces para encontrar lo que los hackers habían añadido. Estaba después de un buen número de líneas en blanco, de manera que al abrir el fichero con un editor de texto normal no era fácil darse cuenta de que habían cosas añadidas…

En Desnivell el ataque fue a más mala leche. Al entrar en la página de administración del blog, intentaba descargar un troyano en mi ordenador. El antivirus detectó el problema. La primera cosa que intenté fue borrar todo WordPress y subir de nuevo la última versión. No funcionó… Evidentemente la nueva versión no machaca el fichero config.php y allí estaba el problema.

Afortunadamente, cuando me disponía a borrarlo todo y empezar de nuevo se me ocurrió que podría ser problema del config.php… Eso sí las líneas añadidas también estaban «escondidas», esta vez, poniéndolas hacia la derecha.

Así que, si tienes problemas con tu WordPress, mírate los ficheros .htaccess y config.php antes de borrar nada.

PS 20090313 NdE El plugin WP Security Scan puede ser una idea para reducir un punto el riesgo de ‘hackeo’…

PS 20090313 NdE Otro lugar en el que buscar ideas: 18 Useful Plugins & Hacks To Protect Your WordPress Blog.

WordPress, ‘titles’, ‘alts’ y ‘captions’…

La interfaz de WordPress avisa que usará el mismo texto para la 'leyenda' de la imagen
¿Debe usarse la 'leyenda' como 'texto alternativo'?

…o títulos, leyendas y textos alternativos, si somos más respetuosos con el idioma. Cuenta WordPress desde hace un tiempo con una interfaz ‘muy apañá’ para subir imágenes a nuestras entradas. Y aún así, cada vez que la uso la maldigo un poco… Y es que esa insistencia en usar un único campo para leyenda (o pie de foto) y texto alternativo de una imagen es bastante contraproducente.

  • Dice el W3C que el atributo title puede anotar diversos elementos (entre ellos, los a y los img). Los agentes de usuario visuales (también conocidos como navegadores) los pueden mostrar, por ejemplo, como «tool tips» si nos paramos con el ratón sobre el elemento en cuestión, mientras que los auditivos (los lectores de pantalla) podrían leer en voz alta el contenido del atributo al pasar por él. Aunque solo es una sugerencia.
  • También cuenta el W3C que el atributo alt debe especificarse para los elementos img y area (y es opcional en input y applet). El atributo da un texto alternativo a la imagen (o applet o…) a usar cuando el agente de usuario no puede mostrarla (como es el caso con los lectores de pantalla o los dispositivos que transforman texto en braille). Para hacernos una idea, si nos estuviesen «contando la página por teléfono» sería lo que querríamos que nos dijesen al llegar a la imagen.
  • Finalmente, según el DRAE, entre otras cosas la leyenda es el texto que acompaña a un plano, a un grabado, a un cuadro, etc. Vamos, el texto que ponen bajo la foto los diarios…

Uno entiende que WordPress exija un ‘título’ para las imágenes: de alguna forma hay que guardarlas en la base de datos. No entiende tanto que coloque ese título como elemento title de las imágenes por defecto y sin preguntar. Pero directamente no le cuadra nada que texto alternativo y leyenda sean una misma cosa: en la mayoría de casos nadie pondría como leyenda la descripción del contenido de la imagen. Cuando el blogger poco familiarizado con temas de accesibilidad (¿podemos suponer que la inmensa mayoría?) sube una imagen, piensa en el pie de imagen… y acaba castigando al que debe usar un lector de pantalla con un texto duplicado y que, de regalo, le deja en muchos casos sin la más remota idea de qué hay en la imagen. Para los que nos preocupamos algo más del tema (no tanto como deberíamos, pero lo tenemos en mente), la herramienta nos obliga luego a buscar en la entrada y poner las cosas como corresponde, haciéndonos perder un minuto innecesariamente. WordPress, además, presume de su atención a los estándares web o sea que, aprovechando que se acerca verisón nueva, ¿por qué no darle un repaso al tema?

WordPress 2.7, el trailer

Pues la verdad es que ya tengo ganas de ver la peli… (Versión grande.)

(Una pequeña reflexión sobre software libre y/o de código abierto… ¿Por qué casi todos los proyectos de este estilo flojean tanto por la ‘pata’ de las interfaces, la usabilidad y la experiencia de usuario? ¿Por qué me sorprende tanto (y tan poco a la vez) que la versión de WordPress que más me apetece probar se centre precisamente en esos puntos? ¿Necesita el código abierto unas lecciones sobre el tema? ¿O quizá las necesiten, directamente, las escuelas de ingeniería en informática?)

Y ahora, con suscripción a los comentarios

Pues eso (un día tengo que contar las entradas de obm que comienzan por ‘pues eso’. Algo me dice que me quedaré sin dedos en las manos :-P), que hemos instalado el plug-in Subscribe to Comments y ahora, si escribís un comentario a una entrada podéis suscribiros por correo electrónico a los comentarios subsiguientes (y después eliminar esa suscripción, desde luego). Ahora mismo el ‘gestor de suscripciones’ está en inglés, me temo, pero aún así creo que puede ser de utilidad.

PS Y que no se me olvide recomendar (creo que lo he hecho otras veces) Plugin Central, un gestor de plugins imprescindible para todo aquel que se gestione su propio blog con WordPress.