¿Usas el plugin PopStats?

Actualización: Finalmente Luis Sancho liberó la versión 2.2.1 del plugin PopStats que principalmente corrige un problema de XSS reportado a su autor hace algunos días.

Las cosas que cambian en esta versión:

  • Corrección de vulnerabilidad XSS: problema originado por no realizar filtros adecuados al momento de guardar y mostrar los valores del referer y la dirección IP que envía el cliente.
  • El plugin sólo inserta código JavaScript y CSS en página de administración del plugin.
  • Arreglado problema con el evento "onload" del objeto window, ahora utiliza el modelo de eventos del DOM.
  • Protección contra ataques de tipo CSRF al momento de limpiar las estadísticas (*).

(*) Al enviar esta propuesta, introduje un bug en el plugin que hace que no se puedan limpiar las estadísticas en la rama 2.0 de WordPress, esto fue originado por que la ubicación de la función check_admin_referer cambia entre las versiones 2.0.x (pluggable-functions.php) y 2.1.x (pluggable.php).


Luego de haber estado usando durante un tiempo el plugin PopStats, hoy mientras revisaba las estadísticas del blog, acabo de darme cuenta que es vulnerable a ataques XSS.

Por el momento no daré los detalles de la vulnerabilidad, pero recomiendo que desactiven cuanto antes el mencionado plugin, puesto que estos valores especialmente preparados se pueden persistir en las tablas que usa para almacenar sus datos.

La (in)seguridad de Internet Explorer

Este último fin de semana, mientras hacía una lectura de los sitios a los que estoy suscrito, encontré una interesantísima entrada en el que describe un bug que hace que Internet Explorer facilite los ataques XSS.

Para los que no siguieron el enlace, intentaré resumir de que trata el bug que se comenta ahí:

En teoría, cualquier documento que es servido por un (valga la redundancia) servidor web, está acompañado por una cabecera Content-type, que indica al navegador el tipo de archivo que es, en base a esto el navegador normalmente asocia una acción (interpretar el documento, pasar el control a otra aplicación o finalmente preguntar al usuario que desea hacer con ese archivo).

El caso es que Microsoft implementó algo que se denomina MIME Type Detection, donde básicamente se usan los primeros bytes de un archivo para intentar determinar el tipo o contenido del mismo, esta característica incluso está mencionado en el RFC 2616 (sección 7.2.1 Type).

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

De la cita, se puede ver que sólo se debe usar esta característica si el servidor web NO envía el Content-type correspondiente para el documento que está enviando al cliente.

Como casi todo en la historia de Internet Explorer, Microsoft tiene su propia forma de interpretar los estándares, y es que gracias a la característica antes mencionada, un archivo de texto plano, imagen u otro tipo de documento puede ser interpretado como HTML siempre y cuando éstos incluyan contenido HTML.

Si alguien tiene Internet Explorer a la mano, puede ver que si entra a http://test.buayacorp.com/xss.txt, se mostrará el mensaje "Esto es un archivo de texto" para un archivo de texto plano que contiene lo siguiente:

code:
<script>alert("Esto es un archivo de texto")</script>

Gracias a este bug, múltiples aplicaciones o sitios que permiten subir contenidos a sus usuarios son vulnerables, entre los que se me vienen a la mente:

  • Fresqui: vulnerable
  • Menéame: al parecer no es vulnerable porque hace una conversión de formato al subir un avatar
  • ANWMP o cualquier sitio que tenga instalado Drupal y permita subir archivos: vulnerable
  • etc, etc.

No recomiendo un navegador en especial (usen Firefox! 😀 ), puesto que fácilmente podría hacer el ridículo con los últimos bugs reportados en varios navegadores.

Migración satisfactoria

Tal como había anunciado en una entrada anterior, hoy mudé el blog a otro servidor de hosting, probablemente esté aquí uno o dos meses, hasta juntar el dinero necesario para contratar un servicio relativamente bueno y no tan caro -o en realidad mientras Jose Antonio no se aburra 😀 .

Sobre el proceso de migración, felizmente todo salió como se esperaba, aunque parece que perdí uno o dos comentarios mientras se realizaba el cambio de DNS.

Lo bueno:

  • Que existen amigos que te apoyan incondicionalmente cuando surgen estos problemas.
  • Los trackbacks/pingbacks funcionarán nuevamente, en el anterior hosting no se permitían por algunas reglas mal definidas para mod_security.
  • Tengo el control total para modificar el DNS del domino buayacorp.com, probablemente haga algunas pruebas con el hosting que contraté en Dreamhost hace algún tiempo.
  • Podré utilizar Windows Live Writer nuevamente, antes no podía el problema que comento en el punto 1.

Lo malo:

  • No estaré mucho tiempo en este servidor, lo cual implica que tendré que sufrir migrar nuevamente.

Lo feo:

  • Gracias a los continuos altibajos en la conexión que brinda Telefónica, la descarga y subida de archivos fue una tarea bastante aburrida.

Si notan algún error o algo no está funcionando muy bien, me sería de mucha ayuda si me lo hacen saber para hacer las correciones del caso.

Finalmente, pido disculpas a todos aquellos que tuvieron problemas mientras intentaban acceder al blog.

Migración de urgencia a nuevo servidor

Por problemas que no viene al caso comentar, entre hoy y mañana mudaré el blog a la cuenta reseller de un amigo, espero que esta medida sea sólo por un tiempo mientras reuno los recursos suficientes para adquirir -nuevamente- un servicio de hosting propio.

Les pido disculpas si durante este proceso la página presenta algunos problemas, uno nunca sabe que puede pasar 😀 .