Vulnerabilidad XSS reflejada en profundidad

En este artículo, discutiremos una de las vulnerabilidades más vistas en las aplicaciones basadas en la web, que es: XSS reflejado.

¿Qué es Cross-Site Scripting?

• Cross-Site Scripting es la vulnerabilidad más común que se identifica en la mayoría de las aplicaciones basadas en web activas. La aplicación web es la colección de entradas de usuario y campos de búsqueda. Este es el operador a través del cual ocurre el ataque Cross-Site Scripting (XSS). En esta entrada del usuario, el atacante ingresa un código JavaScript malicioso, cuyo objetivo es robar sesiones de usuario o realizar una ejecución de código cruel.
   
• Los ataques XSS se desenstringn principalmente debido a una validación y desinfección incorrectas de las entradas del usuario. La entrada elaborada se puede dar a cualquier campo de entrada y viajar fácilmente a un servidor web o base de datos. Si la información se maneja correctamente antes de enviarla al servidor web, la aplicación puede salvarse de un ataque XSS.

Tipos de secuencias de comandos entre sitios:

• XSS reflejado: el ataque XSS reflejado ocurre cuando un script malicioso se refleja en los resultados o la respuesta del sitio web.
• XSS almacenado: los datos maliciosos se almacenan permanentemente en una base de datos y luego las víctimas acceden a ellos y los ejecutan sin conocer el ataque.
• DOM XSS: XSS basado en DOM en el que la carga útil del atacante se ejecuta debido a la modificación del «entorno» DOM ​​en el navegador de la víctima utilizado por el script original del lado del cliente. El código del lado del cliente se ejecuta de manera «inesperada».

XSS reflejado en profundidad:

• Cross-Site Scripting reflejado es el tipo en el que el script inyectado se refleja en el servidor web, como el mensaje de error, el resultado de la búsqueda o cualquier otra respuesta. Los ataques de tipo reflejado se entregan a las víctimas o los objetivos a través de otra ruta, como mensajes de correo electrónico o phishing. Cuando se engaña al usuario para que haga clic en el script o enlace malicioso, este ataque activa el navegador del usuario. Un ejemplo simple de Reflected XSS es el campo de búsqueda.
• Un atacante busca lugares donde la entrada del usuario se usa directamente para generar una respuesta para lanzar un ataque Reflected XSS exitoso. Esto a menudo implica elementos que no se espera que alojen secuencias de comandos, como etiquetas de imágenes (<img>) o la adición de atributos de eventos como onload y onmouseover. Estos elementos a menudo no están sujetos a la misma validación de entrada, codificación de salida y otras rutinas de verificación y filtrado de contenido.

 

En la figura anterior:

• El atacante envía un enlace que contiene código JavaScript malicioso.
• Malicious Link se ejecuta en usuarios normales a su lado en cualquier navegador específico.
• Después de la ejecución, los datos confidenciales como cookies o ID de sesión se envían de vuelta al atacante y el usuario normal se ve comprometido.

Ejemplo 1: considere una aplicación web que toma la string de búsqueda del usuario a través del parámetro de búsqueda proporcionado en la string de consulta.

http://target.com/aform.html?search=Gaurav

El servidor de aplicaciones quiere mostrar el valor de búsqueda proporcionado por el usuario en la página HTML. En este caso, PHP se usa para extraer el valor de la URL y generar el resultado HTML

<?php echo ‘Usted buscó: ‘ . $_GET[“buscar”]; ?>

Compruebe cómo la entrada proporcionada por el usuario en la URL se transmite directamente sin realizar una validación de entrada y sin codificar la salida. Por lo tanto, se puede formar un script malicioso de modo que si una víctima hace clic en la URL, el navegador de la víctima ejecutaría un script malicioso y enviaría los valores de la sesión al atacante. 

http://target.com/aform.html?search=<script>alert(‘XSS por Gaurav’);</script>

Ejemplo 2: XSS reflejado también puede ocurrir cuando una aplicación emplea una página dinámica para mostrar mensajes de error a los usuarios. Básicamente, la página toma un parámetro de entrada que contiene el texto del mensaje y simplemente muestra este texto al usuario dentro de la respuesta. 
Considere la siguiente URL, que devuelve el mensaje de error

http://target.com/error/5/Error.ashx?message=Sorry%2c+an+error+ocurrió

Si verificamos la fuente HTML de la página devuelta, la aplicación simplemente copia el valor del parámetro del mensaje en la URL y lo inserta en la página de error en un lugar adecuado.

<p>Lo sentimos, ocurrió un error.</p>

Como no se realiza desinfección ni validación para el mensaje de error, el atacante puede insertar fácilmente el script malicioso que genera un cuadro de diálogo emergente.

http://target.com/error/5/Error.ashx?message=<script>alerta(“XSS por GAURAV”)</script>

Solicitar este enlace genera una página de respuesta HTML que contiene lo siguiente en lugar del mensaje original.

<p><script>alerta(“XSS por GAURAV”);</script></p>

Mitigaciones:

• Intente utilizar tecnologías de navegador que no permitan secuencias de comandos del lado del cliente en campos de entrada o URL.
• Utilice caracteres de tipo estricto y cumplimiento de codificación para evitar XSS.
• Asegúrese de que todas las entradas proporcionadas por el usuario estén validadas adecuadamente antes de enviarlas al servidor.

Impacto de XSS reflejado:

• El atacante puede secuestrar cuentas de usuario.
• Un atacante podría robar las credenciales.
• Un atacante podría exfiltrar datos confidenciales.
• Un atacante puede robar cookies y sesiones.
• Un atacante puede obtener acceso rápidamente a las computadoras de sus otros clientes.