XSS Cross-Site Scripting (I)

—Maestro, una vez más me atrevo a acercarme a ti con mis preguntitas sobre seguridad.
—Menos guasa, que ya sabes que yo “sólo sé que no sé nada”.
—Bueno, algo sabes…
—¿Qué tripa se te ha ro… digo… en qué puedo ayudarte?
—Estaba leyendo un blog en el que se hablaba de Cross-Site Scripting y, la verdad, no consigo entender de qué va el asunto; ni San Google me ha podido ayudar. Sólo he sacado en claro que el nombre no es del todo descriptivo y que se trata de utilizar una vulnerabilidad para inyectar código en un sitio para obtener datos de un usuario que cree estar visitando otro o algo así.
—Pues efectivamente, se trata de aprovechar una vulnerabilidad y es de lo más interesante. Es uno de los casos en los que puede caer hasta un usuario prudente, ya que no depende de que realice una actividad temeraria durante la navegación. Como sabes que suelo hacer, empezaré por describirte un posible escenario de lo que puede pasarle a un usuario, antes de entrar en la descripción de las interioridades.

“Alicia está leyendo uno de sus blogs favoritos sobre economía. Esta vez hay un post sobre un tema un tanto polémico y, como suele ocurrir, alguno de los comentarios es un poco incendiario, por lo que todos los demás se dedican a darle la razón o a contradecirlo. Alicia, curiosa, navega hasta el comentario en cuestión, lo lee, y aporta su opinión, identificándose previamente como usuaria registrada. El mal ya está hecho.

Al día siguiente, aparece un comentario de Alicia en el que se comporta como un troll, pero no ha sido ella. No es nada muy importante, pero tiene que dar algunas explicaciones al propietario del blog, a alguno de sus conocidos del MundoReal® que saben su nick y, por supuesto, pedir que le den de baja su usuario registrado.

Luego, empieza a ponerse un poco paranoica (o no) y piensa que el mismo usuario y contraseña lo está usando en otros blogs y foros y hasta en su cuenta de ¿flickr? ¿Facebook? … No en nada importante, como el banco online, claro. En fin, te haces una idea, ¿no?”

—Pero ¿qué ha hecho mal Alicia?
—Nada.
—Entonces, ¿de quién es la culpa?
—En este caso, de quien ha desarrollado la plataforma del blog, pero esto puede ocurrir en cualquier aplicación Web que acepte entradas de los usuarios (formularios, blogs, foros).
—Y, ¿cómo funciona?
—La base está en hacer que el sitio web vulnerable te muestre código script que tú has introducido (inyectado) previamente. Por ejemplo, en un campo buscador o en uno de un formulario o, en el caso del blog, en el campo de entrada del comentario. Si en lugar de introducir texto inocuo, el hacker pone código script y el servidor lo almacena o lo devuelve, el navegador de Alicia ejecutaría ese script.
—No acabo de entenderlo. ¿El hacker introduce el código y luego otro usuario lo ve y se ejecuta? Pero el otro usuario estará en otro sitio y en otro momento, ¿no?
—Cierto, te lo explico un poco mejor: el hacker pone un comentario en el blog de antes, pero además de texto normal, introduce un trozo de código en (java)script. Si la aplicación guarda esa información en una BD o en un archivo para uso posterior (como ocurre con los blogs), cuando Alicia accede a los comentarios del blog, el script se muestra, y por tanto se ejecuta en su navegador. Es lo que se llama un ataque stored (almacenado).
—¿Y si no se almacena el texto?
—Entonces, es ligeramente más complejo. Se trata de conseguir que Alicia acceda al sitio vulnerable con toda la información que el atacante necesita ya metida en la URL. Es decir, tiene que “clickar” en una URL que contiene la dirección de la página del sitio vulnerable, el campo correspondiente, el contenido y el “efecto” del click de enviar. Aunque parece complejo, en realidad no es muy complicado construir la URL. En este caso, se trata de un ataque reflected (reflejado).
—¿Cómo consigue el hacker que Alicia clicke en una URL así?
—Normalmente, ingeniería social. Es decir, engañándola. Puede ser con un email en el que se le dice que mire algo en un sitio web (que, además, conoce y en el que probablemente confía), o con una URL con una referencia a una noticia o a otro contenido del sitio Web vulnerable. El usuario clicka porque conoce el sitio destino, pero la URL es maligna y contiene un script. En fin, hay muchas formas.
—Y con eso el hacker consigue…
—Por ejemplo, la cookie de sesión de Alicia, con la que puede suplantarla, obtener y cambiar su contraseña, obtener información privada que tiene el sitio vulnerable, etc. Además, como mucha gente utiliza el mismo usuario y la misma contraseña en varios sitios, puede empezar a acceder a esos sitios, obtener más información … en fin, te haces una idea.
—Entiendo. Y, ¿cómo se puede evitar?
—Desde el punto de vista de Alicia, hay poco que pueda hac…

Ring, Riiinngg

—Vaya, el teléfono. Espera, ahora te cuento.

(Continuará…)