Qué es XSS y por qué debería de importarte

En este post exploraremos que es la vulneravilidad XSS, los daños que puede causar, las distintas herramientas que  aporta Net Framework para mitigar esta vulnerabilidad y algunos ejemplos reales.

¿Qué es Xss?

Cross-Site-Scripting abreviado normalmente como XSS es un tipo de vulnerabilidad web que permite al atacante inyectar código malicioso en el navegador de una víctima. El atacante no tiene como objetivo directo de su ataque al usuario sino aprovecharse de la vulnerabilidad de la aplicación para que esta envíe el código a la víctima usando a la aplicación como cómplice. Las consecuencias de esto pueden llegar a ser desde un simple alert (“Hola mundo”) hasta realizar acciones haciéndose pasar por el usuario.

 Este tipo de vulnerabilidad se produce cuando el código HTML es generado dinámicamente en tanto en el servidor como en el cliente y la entrada del usuario no ha sido limpiada y se refleja de alguna forma en la página web. Esta vulnerabilidad es independiente del servidor y del lenguaje de programación o framework estemos usando.

A pesar de que Javascript se ejecuta en un entorno muy restringido gracias al navegador limitando el daño que pueda hacer al ordenador, puede llegar a suponer un grave problema en otros contextos. Al ejecutarse como si fuese Javascript enviado por el servidor, el código malicioso puede llegar a tener acceso a contenido sensible del usuario. Además de poder realizar peticiones al servidor emulando ser código valido.

¿Qué tipos hay?

Existen 3 tipos de XSS dependiendo de como se transmita la información y si se guarda o no, el persistente, el reflejado y el basado en el Dom.

Persistente

El persistente consiste en que la cadena de caracteres que contiene el código de guarde en algún lugar. Y que posteriormente esta cadena se muestre a en un navegador. El caso más sencillo es aquel en el que en la aplicación se guardar los nombres de usuario, el atacante guardará como nombre de usuario un código JavaScript y posteriormente a la víctima se le muestra una lista de usuarios. Esto causa que el código malicioso sea inyectado en la página. Este tipo de xss tienen la peculiaridad que pueden llegar a afectar a todos los usuarios que visiten la página teniendo un gran impacto sobre la aplicación.

También es posible que este tipo de vulnerabilidad se use junto con otras como inyección SQL para tener aún más puntos de ataque sobre la aplicación. Por ejemplo, si se guarda en la base de datos las entradas de un blog y en una de la entrada se guarda un script, cualquier usuario que visualice esa entrada, estará ejecutando el código del atacante. Por lo que debemos de limpiar tambien toda la informacion que sea externa a la aplicación.

La forma más común de este tipo de vulnerabilidad es aquella en la que el atacante envíe la inyección de código en una caja de texto, el nombre de usuario por ejemplo, y este se guarde en la base de datos. Pero también debemos de limpiar el resto de los parámetros ya que es posible modificar la petición. Por ejemplo, en un servidor que recibe la informacion de un coche se espera que se seleccione una marca de una lista, si el atacante modifica la peticion al servidor es posible que introduzca una valor que sea un script , por lo que debemos de comprobar que todos los parámetros de la petición son seguros no solo aquellos en los que se pueda introducir texto.

Reflejado

También conocido como no persistente es uno de los más comunes y que tiene menor impacto. A diferencia del persistente, el reflejado requiere que el atacante envíe una url al usuario y que este entre en la url infectada por lo que tiene también un componente de ingeniería social. Los usuarios más atentos o con un poco de conocimiento técnico en web pueden llegar a darse cuenta que la url puede ser peligrosa.  Ya que se puede ver en los parámetros de la url algo extraño. Aunque esto se puede evitar usando un acotador de url o una redirección .

Un ejemplo de este tipo de url seria: “htts://servidor.com/busqueda?query=<script>alert(“Hola”) </script>”.

Basado en el Dom.

El xss basado en el dom es muy similar en al reflejado ya que comparten el impacto y la necesidad de ingeniería social, pero se diferencian en que el código malicioso solo se encuentra en cliente, y no se envía en ningún momento al servidor, esto lo hace mas peligroso ya que al no enviarse ninguna petición al servidor, el desarrollador no puede saber si alguien ha podido ser victima de este ataque ya que no se ha podido loggear nada. Y al no pasar por el servidor no es posible aplicar ningún tipo de filtro que normalmente tienen implementados los frameworks web. Esta vulnerabilidad ocurre cuando se extrae información de la url y se inserta en el dom o se ejecuta sin comprobar que esa información sea segura.

¿Qué consecuencias pueden tener?

Las consecuencias de una vulnerabilidad de tipos xss depende del tipo de aplicación y de que parte estén afectadas, los casos mas comunes son:

• El robo de credenciales mediante la lectura de los campos del formulario de inicio de sesión y enviando esos datos al servidor del atacante.
• El robo de cookies como la cookie de sensión que permitiría al atacante ver información sensible del usuario. O hacerse pasar por él.
• Realizar acciones suplantando al usuario como por ejemplo la trasferencia de dinero de una cuenta a otra.

En caso de afectar a solo un usuario el daño es limitado, pero si ese usuario tiene permisos de administrador puede causar que toda la aplicación se vea comprometida.

¿Como prevenirlos?

Para esto no se puede dar una respuesta concreta ya que depende mucho del tipo de aplicación que estemos haciendo y de que lenguaje y framework estemos usando.

Normalmente los framework implementan algún tipo de protección contra este tipo de vulnerabilidad interceptando y bloqueando este tipo de peticiones. Pero se da la opción de deshabilitarlo. A la hora de desarrollar nuestra aplicación deberíamos de intentar no deshabilitarla y en caso de hacerlo implementar alguna medida de seguridad para que los usuarios no estén en peligro. El problema de usar el filtro de los framework es que solo nos protege contra los reflejados y los persistentes. Por lo que debemos de implementar o usar una librería (lo más recomendado) para filtrar todas las entradas de información no seguras y debemos de tener en cuenta en que contexto se va a guardar la información y tener en cuenta su codificación.

XSS sobre Net Framework

Por defecto net framework bloquea todas las peticiones peligrosas que intenten la inyección de código. Por lo que no debemos de preocuparnos de asegurar nuestra aplicación a no ser que permitamos la entrada de código html por parte de los usuarios a nuestra aplicación.

Si aceptamos este tipo de información en nuestra aplicación debemos de tomar mas pasos para que nuestra aplicación sea segura. La forma más sencilla para protegernos es usar las librerías que nos proporciona net framework para codificar la información dependiendo de donde se vaya a añadir, es decir no será la misma codificación para un atributo que para una etiqueta HTML que para QueryString. El motor de vistas razor codifica por defecto todas las variables si no usamos Html.raw() por lo que en las vistas no deberíamos de tener que realizar ninguna acción mas.

En el caso de querer usar los codificadores desde código debemos de usar en Net Core las clases HtmlEncoder, JavaScriptEncoder y UrlEncoder situadas en el namespace System.Text.Encodings.Web y para Net Framework debemos de usar AntiXSSLibrary y HtmlSanitizationLibrary.

Demo de una aplicacion vulnerable.

Para la demostración simularemos una aplicacion en la que se pueden publicar comentarios. El comentario se podea poner publico o privado(esta opcion no esta implementada en el backend). Supongamos que queremos que el usuario pueda introducir codigo html en el comentario para decorarlo pero que no pueda introducir codigo javascript.

En el repositorio solo se han implementados los metodos de obtener todos los comentarios y de insertar un nuevo comentario.En este caso la informacion se guarda en una variable estatica pero en una aplicacion real deberiamos de guardarlo de otra forma como una base de datos aceciendo atraves de una clase Context.

En el controllador Home solo se usa el metodo index. Cuando se accede con el metodo GET se devuelve la lista de comentarios. Cuando se accede con el metodo POST se espera un comentario como parametro de entrada que sera guardado y se redirecciona al metodo index con GET. Usando el atributo [ValidateInput(false)] podemos permitir que se realize una peticion con contenido peligroso como etiquetas html o código javascript.

En la vista se muentran todos los comentarios y un formulario para introducir un nuevo comentario, permitiendo seleccionar si se quiere hacer público o no.

Segun esta la aplicacion ahora, si introducimor <script>alert(1)</script> en la caja de texto, o en el value de el select (usando el inspector de elementos de las herramientas de desarrollo del navegador) podemos observar que nuestra aplicacion es vulnerable a este tipo de ataques.

Para resolver esta vulneravilidad debemos de limpiar la entrada de datos del comentario usando htmlSanitizer.Sanitize, tambien debemos de eliminar el atribute [Validateinput(false)] y poner [AllowHtml] en la propiedad textoComentario del modelo para que solo se permita html en el texto del comentario. Deberiamos de quitar Html.raw de la vista razor y en su lugar usar DisplayFor para la propiedad tipo.

Y tras esto estaríamos seguros ante este tipo de ataques. No se cumpliría el requerimiento de permitir que se introduzca html, si quieres aprender a hacer este busca el termino Rich Text.

Repositorio de Github: https://github.com/IsmaelPerez-Fsts/XSSExample

Algunos ejemplos reales

Google search xss

Si entre el 26 de septiembre de 2018 y el 22 de febrero de 2019  e introducías  <noscript><p title=»</noscript><img src=x onerror=alert(1)>»> en tu buscador de Google te encontrarías con esto:

Esta vulnerabilidad se produjo porque se limpiaba la entrada de usuario en el propio navegador  , la Liberia encargada de esto tenía un bug que causaba una vulnerabilidad de tipo xss. Se desconoce el impacto y si ha sido usado con fines maliciosos ya que al no enviarse al servidor ninguna petición no es posible saber si algún usuario ha sido afectado. Para una explicación mas detallada visita este video https://www.youtube.com/watch?v=lG7U3fuNw3A

TweetDect XSS y el tweet que se retweeteaba a si mismo

Antes de entrar en la vulnerabilidad explicar que twitter es una red social en la que puedes publicas post llamados tweets que todo el mundo puede ver. Y TweetDect es una herramienta para administrar cuentas de twitter que es usada también por algunos de los usuarios. Y dentro de twitter existe una acción que es retweetear que permite que todo el mundo que te sige vea el tweet y se muestre en el perfil tu usuario.

El tweet que se aprovechaba de esta vulnerabilidad es este:

Este tweet se aprovechaba de que TweetDeck no filtraba bien la entrada de usuario y mostraba a los usuarios un tweet que contenía código javascript que se retweeteaba a si mismo obteniendo gran cantidad de retweets sin que el usuario interactuara con el tweet, solo era necesario que se mostrase el tweet  en el navegador para que eso ocurriera. Este seria un ejemplo de xss persistente.

Para mas información visita este video https://www.youtube.com/watch?v=zv0kZKC6GAM

De XSS a control total en Jira

En este caso los atacantes pudieron obtener control total sobre el servicio de jira en The Apache Foundation. Jira es un programa para el desarrollo de proyectos y seguimiento de fallos.  Básicamente los atacantes publicaron un problema en el sistema:

«I’ve got this error while browsing some projects in jira http://tinyurl.com/ybnf8xt«

 Y esta url redirigía a otra que era tal que así.

El mensaje llamo la atención a algunos administradores que accedieron al link provocando que el id de sesión de los administradores se viese comprometida. De este modo los atacante pudieron modificar la configuración de Jira añadiendo código malicioso en archivos que posteriormente los usuarios descargaban. Estos archivos actuaban como virus y realizaban copias del sistema de archivos las victimas o instalaba un backdoor en sus ordenadores. Al final mediante el robo de credenciales pudieron acceder a servidores internos de Apache. Esta vulnerabilidad se trata del tipo reflejada y demuestra lo critico que puede llegar a ser este tipo de vulnerabilidad.

Si quieres aprender mas sobre este suceso entra en este link https://www.netsparker.com/blog/web-security/apacheorg-and-jira-incident/

Conclusión

A pesar de que Xss sea una vulnerabilidad muy fácil de solucionar, es relativamente complicado identificarla ya que requiere conocer la aplicación afectada a nivel muy profundo y el desarrollador debe de tener muy claro el flujo de los datos. Y aunque en algunas ocasiones esta vulnerabilidad hay sido usada mas como algo educativo y sin causar daño alguno es muy posible que alguien mal intencionado pueda llegar causar gran cantidad de daños a una compañía o individuo como ocurrió con Jira.  

Autor/a: Ismael Pérez Lozano

Curso: Microsoft MCSA Web Applications + Microsoft MCSD App Builder + Xamarin

Centro: Tajamar

Año académico: 2019-2020

Repositorio del proyecto: https://github.com/IsmaelPerez-Fsts/XSSExample

Fuentes :