Reflection

En este write-up explicaremos en detalle cómo funciona una vulnerabilidad de Cross-Site Scripting (XSS), y cómo se han resuelto los laboratorios de Reflection.

Introducción a XSS

El Cross-Site Scripting (XSS) es una vulnerabilidad de seguridad web que permite a un atacante inyectar scripts maliciosos en páginas web vistas por otros usuarios. Estos scripts suelen ser ejecutados en el navegador de la víctima y pueden realizar acciones como robar cookies, realizar redirecciones maliciosas, capturar credenciales, entre otras.

Existen tres tipos principales de XSS:

  1. Reflected XSS o XSS reflejado: El script malicioso es introducido por un usuario en una solicitud y reflejado directamente en la respuesta del servidor.

  2. Stored XSS o XSS almacenado: El script se almacena en el servidor y afecta a múltiples usuarios que carguen la página comprometida.

  3. DOM-Based XSS o XSS basado en DOM: La inyección ocurre directamente en el navegador, manipulando el Document Object Model (DOM) en lugar de interactuar con el servidor.

La explotación de XSS se logra mediante el uso de cargas útiles (payloads) específicas que incluyen código JavaScript malicioso, como por ejemplo:

<script>alert('XSS')</script>

A continuación, vamos a resolver los laboratorios de Reflection paso a paso.

Tenemos 4 labs

Laboratorio 1: Reflected XSS

Descripción: En este laboratorio, se proporciona un campo de entrada donde se puede introducir texto. Este texto se refleja directamente en la página web sin ninguna validación o sanitización.

Proceso a seguir:

  1. Introducimos texto simple como "Hola Mundo" y observamos que se refleja sin ningún cambio en la página.

  2. Probamos varios payloads de XSS. Si no conoces ninguno. mi recomendación es que visites este repositorio ( XSS Payloads List) y vayas probando varios y viendo las distintas respuestas. En mi caso, tras probar los básicos, me ha funcionado el siguiente:

    <img src/onerror=prompt(8)>

    • Aquí, src apunta a una imagen inexistente, lo que activa el evento onerror.

    • Al ejecutarse el código, se abre un cuadro de diálogo con el número 8.

  3. Al insertar este payload en el campo de entrada y enviar la solicitud, confirmamos que el XSS se ejecuta correctamente.

Mitigación:

Si quisiéramos evitar un Reflected XSS, tendríamos que hacer lo siguiente:

  • Validar y sanitizar las entradas del usuario.

  • Usar codificación adecuada (HTML-encode) antes de reflejar el contenido en la página.

Laboratorio 2: Stored XSS

Descripción: Este laboratorio almacena el contenido introducido por el usuario en el servidor y lo refleja para otros usuarios.

Proceso a seguir:

  1. Tenemos identificado el campo donde podemos introducir texto que será almacenado en la base de datos.

  2. Probamos los distintos payloads de los que disponemos. En mi caso, pruebo el mismo payload usado antes:

    <img src/onerror=prompt(8)>

  3. Tras enviar la solicitud, el script malicioso se almacena en el servidor.

  4. Cuando la página es visitada por cualquier usuario, el script se ejecuta automáticamente, mostrando el cuadro de diálogo.

Mitigación:

Para evitar un Stored XSS, tedríamos que hacer lo siguiente:

  • Sanitizar todas las entradas de los usuarios antes de almacenarlas.

  • Escapar caracteres especiales (como <, >, ", etc.) antes de renderizar el contenido.

  • Implementar una política de contenido seguro (Content Security Policy - CSP).

Laboratorio 3: XSS con Dropdowns

Descripción: En este laboratorio, tenemos tres menús desplegables cuyas opciones se envían al servidor. El objetivo es modificar el valor enviado para introducir un payload XSS.

Proceso:

  1. Usamos Burp Suite para interceptar la petición cuando enviamos la petición tras elegir las opciones en los menús desplegables.

  2. Una vez interceptada la petición, la enviamos al Burp Repeater.

  3. Una vez en el Repeater, modificamos los valores enviados en la petición, reemplazándolo con el Payload que hemos usado anteriormente, codificado en formato URL (para codificarlo en Burp, seleccionamos el texto y usamos 'Ctrl + U') 

%3Cimg%20src%3D%22%22%20onerror%3Dprompt%288%29%3E
o
<x+onclick=alert(1)>click+this!

  • Esto corresponde al payload original <img src="" onerror=prompt(8)>, pero codificado para evitar problemas de formato.

  1. Enviamos la solicitud modificada al servidor desde Burp Repeater y observamos que el XSS se ejecuta al cargar la página. Podremos ver la respuesta en el navegador, seleccionando 'Show response in Browser'.

Mitigación:

Para evitar un XSS en menús desplegables, tendríamos que hacer lo siguiente:

  • Validar y restringir los valores aceptados en el servidor.

  • Utilizar listas blancas de valores permitidos para cada campo.

Laboratorio 4: XSS Basado en Parámetros GET

Descripción: Este laboratorio nos permite inyectar código a través de parámetros en la URL. El valor del parámetro se refleja en la página web sin ser sanitizado.

Proceso:

  1. Observamos que el laboratorio pide añadir un parámetro ?data= en la URL.

  2. Introducimos nuestro payload directamente en el parámetro:

    Copy

    /?data=<img src/onerror=prompt(8)>

  3. Al cargar la URL modificada en el navegador, el XSS se ejecuta correctamente.

Mitigación:

Para evitar un XSS basado en parámetros GET, tendríamos que hacer lo siguiente:

  • Sanitizar los valores recibidos desde la URL antes de reflejarlos.

  • Escapar los caracteres especiales en las respuestas.

  • Implementar una CSP para reducir el impacto de scripts inyectados.

Conclusión

Estos cuatro laboratorios han demostrado diferentes formas en las que las vulnerabilidades de XSS pueden ser explotadas. La clave para prevenir XSS está en aplicar las mejores prácticas de seguridad en cada nivel del desarrollo, como las que hemos mencionado.

PreviousMachinesNextLogin

Last updated