Cross-Site Scripting (XSS)

El cross-site scripting -referido como XSS- es una vulnerabilidad de la aplicación que tiene el potencial de causar estragos en aplicaciones y sitios web. El XSS está tan extendido y es tan potencialmente dañino que sigue estando incluido en la lista de las 10 principales vulnerabilidades del Open Web Application Security Project (OWASP).

De hecho Cross-Site Scripting es la vulnerabilidad más común descubierta desde 2014 y en 2019 sigue apareciendo en el Top 3 de vulnerabilidades reportadas.

En algunos casos, el script del lado del navegador también puede introducir esta vulnerabilidad permitiendo a un atacante explotarla sin que el usuario objetivo haga una petición a la aplicación web.

Los atacantes explotan el XSS mediante la elaboración de un código malicioso que puede ser dirigido a otro usuario, es entonces ejecutado por el navegador desprevenido. Como la mayoría de las veces el script se incluye en el contenido de la respuesta de la aplicación web, se ejecuta y tiene el mismo acceso que si el script fuera legítimo. Se puede permitir el acceso a los tokens de sesión, a las cookies e incluso a la información confidencial o sensible a la que el navegador tiene acceso en ese sitio, incluso reescribiendo el contenido de la página HTML.

Ataques XSS reflejados

En los ataques XSS reflejados, el script malicioso se inyecta en una petición HTTP (normalmente mediante un enlace específicamente diseñado que se proporciona al usuario). Como la variedad más simple, utiliza parámetros de entrada en la solicitud HTTP que pueden ser fácilmente manipulados para incluir el contenido del script dañino. El script malicioso se refleja desde el servidor en una respuesta HTTP y se ejecuta en el navegador de la víctima.

En este caso, actúa como un XSS almacenado sin almacenar realmente datos maliciosos en el servidor.

Aquí hay un ejemplo de ataque XSS reflejado:

Digamos que example.com/profile contiene un parámetro de nombre. La URL de la solicitud se vería así: https://example.com/profile?user=Tammy. Basándose en esta entrada, la aplicación web respondería así con «Hola Tammy» en la parte superior de la página. Si los parámetros no se validan para asegurar que sólo contiene los datos esperados, un atacante podría hacer que un usuario visite una versión maliciosa de la URL como esta: https://example.com/profile?user<script>some_malicious_code</script>.

Cuando la respuesta se envía al navegador, incluye ese script malicioso, que luego se ejecuta en el navegador, probablemente sin que el usuario lo sepa. Este es un ejemplo de ataque XSS reflejado, ya que el código malicioso se «refleja» inmediatamente en el usuario que realiza la solicitud.

Ataques XSS almacenados

En lo que se conoce como ataque XSS almacenado o persistente, el contenido malicioso se entrega directamente, junto con la respuesta del servidor cuando el usuario carga una página web. Así, el contenido ya está almacenado en la base de datos del sitio web (de ahí el nombre de este tipo de ataques). Los usuarios simplemente entran en la página web hackeada y son víctimas de estos ataques.

Cada uno de los usuarios que abre un sitio web comprometido corre el riesgo de que le roben sus datos personales, por lo que podría considerarse el tipo más peligroso de ataque XSS.

¿Pero cómo llega el contenido malicioso a la base de datos para empezar? En la mayoría de los casos, se introduce a través de formularios de páginas web desprotegidos en los que la entrada del usuario no está debidamente validada y saneada. Si los datos introducidos por un hacker no se validan tanto en el lado del cliente como del servidor, se guardarán en la base de datos. Por ejemplo, este tipo de entrada podría incluir un área de texto para comentarios, un editor de texto para publicaciones, un editor de datos personales u otros formularios.

Una vez que un atacante consigue enviar contenido malicioso al servidor y ese contenido aparece sin filtrar en una página web, todos los usuarios se convierten en víctimas potenciales.El remedio común para los ataques XSS almacenados es sanear la entrada tanto en el front end como en el back end de la aplicación. La desinfección implica una combinación de validación de datos y escape de caracteres especiales o filtrado completo de los mismos, y es una práctica habitual para la seguridad de la web y de JavaScript.

Ataques XSS basados en DOM

El Modelo de Objetos del Documento (DOM) es una interfaz que permite a las aplicaciones leer y manipular la estructura de una página web, su contenido y su estilo. En un ataque XSS basado en el DOM, la vulnerabilidad se encuentra en el código de script del lado del navegador y puede ser explotada sin ninguna interacción con el servidor, modificando el entorno en el navegador de la víctima desprevenida.

A veces, los ataques XSS basados en el DOM son similares a los ataques reflejados. El ejemplo anterior de un ataque XSS reflejado puede aplicarse en este caso con una sola suposición: La aplicación web lee los datos directamente desde una cadena de consulta.

Digamos que la aplicación utiliza el parámetro de consulta «nombre» para mostrar instantáneamente el nombre del usuario en la pantalla mientras espera a que se cargue el resto de una página. Sin una validación adecuada, esto puede dar el mismo resultado que con un ataque reflejado, si el hacker tiene éxito en hacer que la víctima abra un enlace sospechoso.

Al igual que con el XSS almacenado, para prevenir los ataques reflejados y basados en el DOM, los desarrolladores deben implementar la validación de datos y evitar mostrar la entrada cruda del usuario, a pesar de la presencia o ausencia de comunicación con el servidor.

¿Cuáles son los vectores de ataque de Cross-site Scripting?

Hay varios vectores comúnmente utilizados en los ataques XSS:

• <etiqueta script>: Una etiqueta script puede utilizarse para referenciar código JavaScript externo, lo que hace que este sea el punto XSS más sencillo. Los atacantes también pueden incrustar el código malicioso dentro de la etiqueta script.
• Eventos JavaScript: Otro popular vector de XSS utilizado por los atacantes, los atributos de eventos, pueden ser aplicados en una variedad de etiquetas. Atributos como «onerror» y «onload» son ejemplos.
• <body> etiqueta: Los atributos de eventos también pueden ser la fuente del script cuando se proporcionan a través de la etiqueta «body».
• <img>: Dependiendo del navegador en uso, este atributo puede ser útil por los atacantes para ejecutar el código JavaScript.
• <etiqueta iframe>: Especialmente eficaz para los ataques de phishing, este vector permite que el ataque XSS incruste otra página HTML en la página actual.
• <etiqueta input>: Algunos navegadores permiten la manipulación a través de este vector, que puede ser utilizado para incrustar un script.
• <link> tag: Esta etiqueta puede contener un script, en lugar del uso normal de enlazar a hojas de estilo externas.
• <tabla> etiqueta: Donde el atributo de fondo normalmente se refiere a una imagen, esto podría ser comprometido para referirse a la secuencia de comandos infractor.
• <div> etiqueta: Esta etiqueta también contiene una referencia de fondo y puede utilizarse del mismo modo que <table> para referirse a un script.
• <objeto> etiqueta: Los scripts de un sitio externo pueden incluirse utilizando esta etiqueta.

Aunque existen otros vectores que los atacantes de XSS utilizan en sus esfuerzos por robar información y comprometer sitios web, estos son algunos de los métodos más utilizados. Los desarrolladores deben adherirse a las prácticas adecuadas de escape y sanitización para protegerse de tales ataques.

Dependiendo del atacante y su intención maliciosa, los ataques XSS pueden resultar en diferentes impactos incluyendo:

• secuestrar la sesión de un usuario, utilizando credenciales para acceder a otros sitios o redirigir al usuario a sitios web no deseados,
• alterar las páginas del sitio web o insertar secciones en una página web,
• ejecutar scripts para extraer información sensible de las cookies o bases de datos,
• si la víctima tiene derechos administrativos, el ataque podría extenderse al lado del servidor, causando más daños o recuperando información sensible adicional.

Los pasos clave en las pruebas de vulnerabilidades XSS para aplicaciones web críticas incluyen:

• utilizar una herramienta de escaneo de código para detectar vulnerabilidades que permitan corregir el código durante el proceso de desarrollo,
• implementar una funcionalidad de prueba automatizada que revele las posibles vulnerabilidades de forma exhaustiva y rápida.

Supongamos que exmple.com/profile contiene un parámetro de nombre. La URL de la solicitud sería como https://example.com/profile?user=Tammy. La aplicación web responde con «Hi Tammy» en la parte superior de la página basándose en esta entrada.

Si el parámetro de usuario no se valida para asegurarse de que sólo contiene los datos esperados, un atacante podría hacer que un usuario visitara una versión maliciosa de la URL con el siguiente aspecto:
https://example.com/profile?user<script>some_malicious_code</script>.
Cuando la respuesta se envía al navegador, incluye ese script malicioso que se ejecuta en el navegador, probablemente sin que el usuario lo sepa. Este es un ejemplo de ataque XSS reflejado. El código malicioso se «refleja» inmediatamente en el usuario que realiza la solicitud.

• Educación y concienciación: Asegúrese de que todos los desarrolladores, diseñadores de sitios web y equipos de control de calidad son conscientes de los métodos que utilizan los hackers para explotar las vulnerabilidades y proporcionar directrices y mejores prácticas para la codificación. Esto incluye técnicas de escape/codificación adecuadas para el entorno de la aplicación (JavaScript, HTML, etc.).
• Sanear la entrada: Ya sea para páginas web internas o sitios web públicos, nunca confíe en la validez de los datos introducidos por el usuario. Examine y valide cualquier campo de datos, especialmente si se incluirá como salida HTML.
• Analice el código: Implemente un software que escanee el código en busca de vulnerabilidades, incluyendo el cross-site scripting, para asegurar que se siguen las mejores prácticas y minimizar la exposición a XSS y otras vulnerabilidades de la lista OWASP.
• Política de seguridad de contenidos: Utilizar la Política de Seguridad de Contenidos (CSP) para definir lo que un sitio web puede hacer, y con ello reducir el riesgo de un ataque XSS. Mediante el uso de CSP, el XSS puede bloquearse por completo (bloqueando todos los scripts en línea) o reducirse a un riesgo mucho menor.

OWASP proporciona orientación adicional sobre cómo prevenir la vulnerabilidad XSS con una completa hoja de trucos.