Saltar al contenido

Ataques en entornos WEB – XSS

Compartir en:

Las aplicaciones web son las plataformas más atacadas debido a varios problemas derivados de la manera de su manera de funcionar(el 75% de los ciberataques están relacionados con los sistemas WEB). XSS es uno de los ataques más sencillos y potencialmente molestos que se pueden dar sobre estas plataformas.

Ataques XSS iberasync
XSS

La arquitectura WEB funciona proporcionando una vista de los datos que se envía desde el servidor hasta un software (navegador) que se encarga de interpretar el código y ofrecer  al usuario una interfaz para interactuar (aprende más de la arquitectura cliente-servidor, modelo de 3 capas y push y pull).

El problema de este tipo de arquitectura es que las aplicaciones deben ejecutar tareas en el lado del cliente, donde es este el que tiene todo el control tanto del código como de las llamadas. Esta situación genera mucha problemática en el ámbito de la seguridad, ya que se debe ser muy cuidadoso a la hora de plantear los sistemas y su código-arquitectura, puesto que es relativamente sencillo para un atacante manipular la información que se envía al servidor.

Además, se necesita por defecto una configuración accesible para que los clientes puedan consultar los datos, es decir, que deben exponerse a una LAN o WAN donde cualquiera (cualquier parte del mundo en el caso de una WAN) pude intentar romper la seguridad del sitio.

Se vuelve muy importante ser extremadamente cuidadoso en la manera que se configura el servidor y sobre todo en la gestión de la información que se recibe por parte de un cliente, por defecto, debemos sospechar que cualquier comunicación pude ser maliciosa, esto engloba también el controlar o conocer las posibles vulnerabilidades que nuestro sitio pueda tener derivadas de nuestro código, nuestra configuración o de los sistemas que se utilizan.

La mayoría de vulnerabilidades, por tanto, permiten a personas no autorizadas robar/modificar/consultar los datos de los aplicativos (bases de batos), en general suelen estar orquestados por Script Kiddies que simplemente detectan vulnerabilidades con herramientas ajenas y ejecutan ataques conocidos, pero estas pueden ocasionar muchos problemas y perdidas a las organizaciones, hasta la más mínima fuga de información pude desembocar en una catástrofe.

A continuación voy a comentar uno de los ataques más frecuentes y simples que se suelen utilizar de manera habitual.

Cross-site scripting (XSS)

El ataque Cross Site Scripting es una de las técnicas mas utilizadas para realizar ataques del lado del cliente en software creado con arquitectura cliente servidor, principalmente WEB.

La técnica de manera muy resumida se basa en la falta de validación de parámetros de entrada del sitio atacado, ya sea en cabeceras HTTP, en parámetros o en texto legítimo que los sitios permiten grabar (comentarios, entradas, …).

Los atacantes se aprovechan de la confianza que el usuario puede llegar a tener en un sito WEB, y fuerzan al sitio a hacer tareas ilegítimas explotando errores.

Al no existir una validación correcta de los diferentes vectores de entrada, los atacantes pueden inyectar una porción de código malintencionado que se ejecutará en el navegador de la víctima, realizando numerosas tareas que parecen legítimas a ojos del usuario.

Una vez se descubre alguna entrada válida para el atacante, este puede inyectar código ilegítimo en el propio servidor del sitio atacado, pudiendo provocar por ejemplo que los usuarios legítimos utilizan un formulario web que parezca real, pero que en realidad haya sido creado íntegramente por un atacante para recopilar datos.

Ataque XSS

En la imagen anterior podemos ver el proceso donde un atacante introduce un script malicioso que ese graba en el servidor legítimo (en un comentario, por ejemplo). Los demás visitantes recorren el sitio web legítimo, pero al ver el comentario del atacante, este ejecuta el código malicioso, por ejemplo, un secuestro de cookies de sesión o de datos de uso.

Pruebas en Google Gruyere

Para poner a prueba este tipo de vulnerabilidades voy a utilizar Google Gruyere, que es una web llena de fallos proporcionados por Google para ver de forma práctica estos tipos de ataques.

Aquí tenéis el enlace de la documentación para que lo probéis:

https://google-gruyere.appspot.com/part2

La prueba más sencilla a ejecutar está relacionada con la no protección de las entradas por parte de la web. Se trata de un Stored XSS a través de un atributo HTML. Vemos que en la web de Google los usuarios pueden poner Snippets o fragmentos de texto donde puedes comentar ¡tus gustos por los quesos!.

Snippet Google Gruyere
XSS
Ataques
Snippet Google Gruyere

Cuando vamos a crear nuestro Snippet personalizado, podemos ver la primera pista de que podemos hacer para indagar en algún error de programación:

Añadir Snippet

Vemos que desde la dirección de Google Gruyere, se ha permitido a los usuarios utilizar HTML en los comentarios para poder dejar sus mensajes bonitos. El permitir HTML por parte de los usuarios es relativamente peligroso en el ámbito de la seguridad.

Muchos errores de este tipo (afortunadamente cada vez menos) vienen dados por no controlar que es lo que graban los usuarios de las plataformas en nuestro sitio web, en este caso, podemos ver que, al permitir cierto código HTML, es posible enmascarar acciones ilícitas en este, por ejemplo, podemos probar 2 cosas, a introducir directamente un <script> o a introducir acciones directamente en las etiquetas permitidas.

En primer lugar, probaremos con la etiqueta <script>, parece muy obvia, pero os sorprendería el resultado de estas pruebas en sitios relativamente conocidos.

Snippet XSS

Al grabar el snippet, podemos comprobar que nuestro ataque ¡ha fracasado!

Snippet creado en Google Gruyere

Si escudriñamos el código HTML podemos ver que la página ha tenido en cuenta mi idea mal intencionada, y ha borrado la etiqueta de JavaScript ‘<script></script>’.

HTML Snippet

Viendo el código que trata las etiquetas (normalmente no tendremos acceso al código, pero me parece didáctico mostrarlo) podemos ver que, si la etiqueta no está permitida, el sistema la sustituye por <blocked>:

Captura código fuente Google Gruyere
Captura código fuente Google Gruyere

Podemos ver en la línea 75 como Google Gruyere limita el tipo de etiquetas que permite, y además en la línea 80 también prohíbe ciertos atributos que pueden dar lugar a fallos de seguridad.

Sabiendo esto, vamos a probar pues con las etiquetas permitidas, por ejemplo, con una negrita <b> que está permitida para que los usuarios den formato HTML, sin embargo, algunos atributos están también bloqueados, ¿podéis ver alguno que esté permitido?, efectivamente, hay un problema de seguridad al permitir el atributo “onmouseover” que desencadenara un evento cuando el usuario pase el ratón por encima de la palabra concreta.

Probemos este fallo:

Test XSS

Ponemos una alerta en la etiqueta «b» que nos diga «pillado» cuando alguien pase el ratón por encima de «El Queso».

Y comprobamos que ha entrado hasta la cocina, tanto en el código como en el funcionamiento:

XSS en Snippet

La prueba es muy simple, y como podéis ver un mensaje en el navegador es inofensivo, pero si el script en vez de un mensaje lee nuestra cookie de sesión, esto ya no tiene tanta gracia, ¿verdad?:

Xss Cookie

Simplemente he añadido:

<b onmouseover='alert(document.cookie)'>Tengo tu cookie!</b>

Con un fallo de este calibre, imaginaros que sois asiduos a entrar en esta web, sois tremendamente fanáticos del queso, al pasar el ratón por un comentario de un usuario, automáticamente el propio código grabado en el servidor y que tu navegador está interpretando, envía tus datos personales (mediante una llamada AJAX por ejemplo) a un servidor creado para robar tus datos.

Parece bastante grave ¿Verdad?, tú estás entrando en el servidor oficial del sitio, con todos sus certificados, etc., sin embargo, este pequeño error está provocando que roben los datos sin ni siquiera enterarte y sin ni siquiera pasar por el servidor del sitio, simplemente es tu navegador el que está enviando los datos.

Como evitar este tipo de ataques

Este tipo de ataques basan su eficacia en como se permite la entrada de datos por parte de los clientes al servidor, ya sea en forma de mensajes, llamadas, archivos o simple texto, por lo tanto, para evitar errores es necesario ser muy minucioso en como tratamos las entradas de datos, sobre todo, aquellas que admitan caracteres peligrosos.

Hay multitud de técnicas, frameworks e incluso librerías para tratar este tema, os pongo los principales métodos de manera genérica:

  • Validación de los datos de entrada

Es importante en cada entrada, comentario o interacción directa, conocer que datos se esperan y son los correctos, e intentar limpiarlos o “sanitizarlos” antes de que el servidor los trate para almacenarlos o registrarlo.

  • Filtrado y cribado

Buscar y eliminar palabras/texto que se utiliza en ataques conocidos o innecesarias como “<script>” o marcados HTML es bastante eficaz a la hora de no permitir ataques XSS, esto es básico a la hora de codificar entradas de texto.

  • Caracteres de escape o inválidos

Los atacantes en ocasiones intentan burlar la seguridad utilizando caracteres de escape conocidos, hay multitud de técnicas y librerías que ayudan a que el texto se mantenga como texto sin tener en cuenta su contenido.

Desde Microsoft, por ejemplo, nos dan una serie de tips para sistemas ASP.net Core 6 https://docs.microsoft.com/es-es/aspnet/core/security/cross-site-scripting?view=aspnetcore-6.0 las cuales nos dan consejos útiles de conversión de etiquetas y tratamientos de datos mediante Razor.

Conclusión

Hemos visto que los servidores web son los más vulnerables dadas las características de su arquitectura y funcionalidad, y por este hecho son también los más atacados.

Conocer como funcionan los ataques nos hace ser más consientes de cómo defendernos y como crear nuestros sistemas de manera más segura.

XSS es solo un pequeño ejemplo de los miles de técnicas para atacar sitios web, desde luego es imposible testearlas todos, pero el conocer sobre todo el TOP 10 de OWASP https://owasp.org/www-project-top-ten/ .

Fuente https://owasp.org/Top10/

Utilizar técnicas de codificación seguras, y crear desde el minuto cero nuestro desarrollo pensando en la seguridad, nos ayudará a evitar muchos quebraderos de cabeza futuros, por tanto, debemos formarnos constantemente en ataques y su ejecución para poder defender nuestras plataformas.

Recordar esta frase que, aunque fue dicha por el IRA a Margaret Thatcher después de un atentado fallido, es perfectamente extrapolable a nuestros sistemas:

“Solo necesitamos tener suerte una vez. Vosotros necesitáis tener suerte siempre”

El IRA a Margaret Thatcher.

Juan Ibero

Inmerso en la Evolución Tecnológica. Ingeniero Informático especializado en la gestión segura de entornos TI e industriales, con un profundo énfasis en seguridad, arquitectura y programación. Siempre aprendiendo, siempre explorando.

Compartir en:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *