Defective code III. XSS (Cross Site Scripting)

En esta ocasión vamos a describir porque se produce y cómo podemos mitigar los posibles defectos de programación que favorecen que usuario malintencionado pueda aprovechar para realizar un ataque de Cross Site Scripting. Esta brecha de seguridad aparece en la lista Top 10 de OWASP 2017 en el tercer puesto por lo que es un problema que se produce con muchísima frecuencia en aplicaciones y páginas WEB.

¿Que es XSS?

Sería un ataque que se aprovecha la confianza en el usuario por parte de un servidor WEB, usuario que debido a esta confianza ejecuta código javascript en el navegador de una víctima, en el ámbito de la sesión del dominio de la WEB vulnerable. El atacante sería capaz de realizar cualquier operación como si fuera un usuario legítimo, acceder a cualquier información de la víctima o robar las cookies de sesión para llevar una suplantación de identidad o incluso modificar la apariencia de una determinada WEB. Son muchísimas las posibilidades de explotación que ofrece a un atacante, por ello debemos tener especial cuidado a la hora de no permitir esta vulnerabilidad en nuestro código.

Dependiendo de la técnica y entorno se puede clasificar en cuatro subgrupos:

-Reflected. Esta primera técnica será la más fácil de mitigar es la conocida como XSS reflejada, el fallo se encuentra en la falta de filtrado en los datos de entrada por parte del usuario en operaciones GET y POST.

-Stored. Conocido como XSS persistente, en este caso lo que un atacante conseguiría que la propia infraestructura almacenará nuestra inyección y la devuelva a los usuarios como si de contenido legítimo se tratase.

-DOM.Document object model como ya sabemos es la interfaz que usa el navegador para acceder, representar y modificar los objetos de la WEB. A través del DOM seríamos capaces de añadir contenido dinámicamente a una WEB mediante javascript, esta acción la realizaremos en los eventos que produce el usuario como el click del ratón y realizar redirecciones que pudieran ser a una página maliciosa.

-Mutated.Es la enos conocidad de las tecnicas XSS y la más difícil de prevenir. Consiste en aprovecharse de las propiedades del innerHTML que convierte un string con código HTML en parte del DOM parseando etiquetas y atributos, con lo que una entrada en apariencia inofensiva puede transformarse al introducirse en el innerHTML y devolvernos una salida maliciosa.

Como se explotarían estas debilidades.

Reflected:

Veamos el siguiente código fuente.

Como observamos el servidor devuelve la página con el valor del parámetro GET ‘name’ incrustado en el cuerpo por lo que alguien podría intentar insertar lo siguiente:

Con lo que se nos devolverá una página HTML con el script ejecutando la alerta la cual en vez de ser con valor 1 podría ser con la cookie de sesión.

El ataque consistiría en forzar a la víctima a visitar el enlace malicioso con la WEB infectada que pudiera contener un iframe oculto capturando toda la información que la víctima estuviera insertando en la WEB confiable.

Existen multitud de maneras de prevenir esta vulnerabilidad cada framework o lenguaje de programación tiene sus propias herramientas en este caso vamos a ver un ejemplo de ello.

En PHP por ejemplo existe la función htmlentities() como se observa en el siguiente ejemplo.

Dicha función realiza el filtrado de los parámetros de entrada, pero debemos de ser muy escrupulosos a la hora de utilizarla puesto que un error en la utilización pudiera ser aprovechado por el atacante para saltarse nuestro filtrado.

Stored:

Un ejemplo de explotación sería el típico sistema de comentarios de una WEB en el cual cualquier usuario puede insertar un comentario en el. Estos comentarios serán almacenados en la aplicación por ejemplo mediante una base de datos y el resto de usuarios verán el contenido cuando visiten la WEB. Ahora pensemos que un atacante logra incluir código javascript en el comentario, con lo que cualquier usuario que visite la página estaría ejecutando el código en su navegador.Veamos el siguiente ejemplo.

La solución sería aplicar el mismo filtrado visto en Reflected pero en este caso filtrando la salida de la persistencia y la entrada del usuario ya que cualquier entrada de usuario puede ser peligrosa y también lo puede ser cualquier salida de la persistencia.

DOM:

Un ejemplo sencillo podría ser el siguiente.

Podríamos incluir perfectamente un script dentro y el servidor no se enteraría de que se está atacando a sus usuarios puesto que las peticiones que a el le llegan son normales. La solución pasaría por tener en cuenta los sources y los sinks aunque no existe una receta global. Lo más usado es crear un sandbox para que no se pueda acceder a los objetos globales y sus métodos.

Mutated:

Puede darse el caso de que una entrada que en principio no es maliciosa mute al introducirse al innerHTML y nos de una salida que si lo es.

Entrada:

Salida:

Este problema hay que tenerlo muy en cuenta a la hora de utilizar frameworks como AngularJS para javascript.

Conclusión.

Hasta no hace mucho no se le ha dado la suficiente importancia a este tipo de ataques, puesto que no se veía su criticidad, pero se ha demostrado que son muy peligrosos de cara a nuestros usuarios, por lo que en mi opinión hay que tener esta vulnerabilidad en mente a la hora de generar nuestro código.

Piensa mal y acertarás codificando de una manera más segura, aunque la seguridad completa no existe.

Espero que sea de vuestro interés y gracias por leerme.

Un saludo.

Referencias.

https://www.owasp.org/index.php/Spain

http://www.dvwa.co.uk