Ataques Web - Demostración - XSS Almacenado

XSS stored, también llamado XSS directo o persistente, consiste en embeber código HTML o Javascript en una aplicación web pudiendo llegar incluso a modificar la propia interfaz de un sitio web (defacement). Al igual que en el caso de XSS reflejcted, esta vulnerabilidad compromete la seguridad del usuario y no la del servidor.

La diferencia frente a XSS reflected es que este tipo de vulnerabilidad es persistente (de ahí que se le conozca también por ese nombre) ya que el código malicioso insertado generalmente es almacenado en una base de datos.

A modo de ejemplo, se considera el siguiente sitio web:

Un blog de noticias sobre Informática donde cada artículo permite la inclusión de comentarios por parte de sus usuarios. Una vez enviado un comentario, el contenido de éste será insertado en la base de

datos e inmediatamente visible en la página del artículo.

Tras descubrir cómo inyectar código en la web, las posibilidades que ofrece esta vulnerabilidad al atacante son diversas:

• Inyectar código que robe las cookies del resto de usuarios.
• Inyectar código que redirecciona la página web a una página externa.
• Realizar un deface a la interfaz con el propósito de estropear el diseño web.
• Troyanizar un gran número de navegadores de usuarios, tomando un control remoto sobre muchos navegadores.

En el nivel de seguridad low el código fuente vulnerable es el que se muestra a continuación:

Este script recoge la información enviada a través del siguiente formulario, en el que los visitantes de la web pueden dejar un mensaje con su nombre (a modo de libro de visitas). Ambos campos son filtrados con la función trim() y mysql_real_escape_string() antes de ser insertados en la base de datos.

Así mismo, el campo correspondiente al mensaje pasa por la función stripslashes() para eliminar las barras en caso de que el mensaje contenga comillas escapadas. Sin embargo no se realizar ningún filtrado para eliminar código HTML que pudiera contener el mensaje…

Una vez que se pulsa en el botón de envío del formulario, el nombre y el mensaje quedan grabados en la base de datos y al volver a cargar la página se mostrarán bajo dicho formulario:

Para comprobar si es vulnerable a XSS en el campo textarea mtxMessage esta vez introduciremos un tag HTML con el que lanzar una ventana de alerta Javascript:

<script> alert("Vulneravilidad low")</script>

El resultado de esta acción es que el mensaje se ha guardado correctamente en la base de datos y en cada carga de la página del libro de visitas se muestra la alerta esperada:

Un usuario mal intencionado podría, por ejemplo, provocar un deface del sitio web, modificando la estructura de la página pudiendo llegar en algunos casos a hacer ilegible su contenido.
Por ejemplo, inyectar:

</div></div></div></div><div>Qué lástima

provocaría un cambio en la estructura HTML de la página web y, por consiguiente, del aspecto general de la página web:

En el nivel de seguridad medium el código difiere nivel low en el uso de la función strip_tags() para eliminar los tags HTML que pudiera contener el mensaje y el uso de str_replace() para eliminar la etiqueta <script> del campo correspondiente al nombre:

Mediante la combinación de las funciones strip_tags() y htmlspecialchars() el ataque a través de este campo textarea ha quedado sin efecto como se comprueba en la siguiente figura:

Por su parte, el campo input correspondiente al nombre no es seguro. El único filtro antes de ser insertado a la base de datos es el realizado con la función str_replace() para eliminar coincidencias con el tag <script>. Esta medida se muestra insuficiente debido a que podría hacer uso del mismo tag con la adición del parámetro type, con lo que ya no se produciría coincidencia y pasaría el filtro. Es más, podría incluso inyectarse cualquier otro tag HTML.

Sin embargo, el código HTML del formulario no permite la inserción de más de 10 caracteres.

<input type="text" maxlength="10" size="30" name="txtName">

Esta limitación no supone un problema puesto que, como vimos en la vulnerabilidad CSRF, Firebug permite la edición inline del código fuente de una página web, por lo que a través de esta herramienta eliminaremos ese parámetro del campo input y, por consiguiente, se podrá inyectar cuanto texto permita el tipo de campo definido en la base de datos.

<SCRIPT language="javascript">window.location="http://webexterna.com";</SCRIPT>

Como se observa en la siguiente figura, la entrada con el código inyectado fue insertada en la base de datos:

Una vez inyectado el código, cada vez que algún usuario intenta cargar la página web, es redireccionado a la página principal del buscador Google España.

Si el filtrado no permitiera la inserción del tag <script> en ninguna de sus formas, se podría haber inyectado la etiqueta <meta> para provocar este mismo efecto:

<html><meta http-equiv="refresh" content="0;url=http://www.google.es/"></html>

Prevención

Para evitar este tipo de vulnerabilidad se recomienda filtrar siempre la información procedente del usuario antes de hacer uso de ella. Generalmente con filtrar los caracteres “<” y “>” sería suficiente, aunque se recomienda también filtrar los nombres de las etiquetas que pueden resultar peligrosas en este tipo de ataque como <script>, <object>, <applet>, <embed> y <form>.

Por su parte, DVWA en el nivel de seguridad high hace uso de las funciones stripslashes(), mysql_real_escape_string() y htmlspecialchars().

Las medidas de seguridad para filtrar la información recibida del formulario son las mismas que en el caso de la vulnerabilidad XSS reflejected con la diferencia de que también ejecuta la función mysql_real_escape_string() antes de insertar la información en la base de datos.

Otra contramedida enfocada a los propios usuarios de páginas web es la de tener el navegador lo más actualizado posible. Por ejemplo el navegador Internet Explorer a partir de su versión 8, introduce como novedad un filtro Anti XSS que detecta posibles manipulaciones de la página mediante la inyección de código en un parámetro de la URL.