
Reflected XSS
En esta sección, explicaremos el cross-site scripting reflejado, describiremos el impacto de los ataques XSS reflejados y detallaremos cómo encontrar vulnerabilidades XSS reflejadas.
¿Qué es Reflected XSS – (cross-site scripting reflejado)
El cross-site scripting (o XSS) reflejado surge cuando una aplicación recibe datos en una solicitud HTTP e incluye esos datos en la respuesta inmediata de forma no segura.
Supongamos que un sitio web tiene una función de búsqueda que recibe el término de búsqueda proporcionado por el usuario en un parámetro de URL:
https://insecure-website.com/search?term=gift
La aplicación repite el término de búsqueda proporcionado en la respuesta a esta URL:
You searched for: gift
Suponiendo que la aplicación no realiza ningún otro procesamiento de los datos, un atacante puede construir un ataque como este:
https://insecure-website.com/search?term=
Dentro de la solicitud del atacante, este comentario estaría codificado en URL como:
You searched for:
Si otro usuario de la aplicación solicita la URL del atacante, el script proporcionado por el atacante se ejecutará en el navegador del usuario víctima, en el contexto de su sesión con la aplicación.
Edición empresarial de Burp Suite
Más seguro no debería significar menos ágil.
Escanéalo todo. Con el escáner de vulnerabilidad web dinámico habilitado para empresas.
Impacto de los ataques XSS reflejados
Si un atacante puede controlar un script que se ejecuta en el navegador de la víctima, normalmente puede comprometer completamente a ese usuario. Entre otras cosas, el atacante puede:
- Realizar cualquier acción dentro de la aplicación que el usuario pueda realizar.
- Ver cualquier información que el usuario pueda ver.
- Modificar cualquier información que el usuario pueda modificar.
- Inicie interacciones con otros usuarios de la aplicación, incluidos ataques maliciosos, que parecerán originarse en el usuario víctima inicial.
Hay varios medios por los cuales un atacante puede inducir a un usuario víctima a realizar una solicitud que controle, para entregar un ataque XSS reflejado. Estos incluyen colocar enlaces en un sitio web controlado por el atacante, o en otro sitio web que permita generar contenido, o enviar un enlace en un correo electrónico, tweet u otro mensaje. El ataque podría estar dirigido directamente contra un usuario conocido, o podría ser un ataque indiscriminado contra cualquier usuario de la aplicación:
La necesidad de un mecanismo de entrega externo para el ataque significa que el impacto del XSS reflejado es generalmente menos severo que el del XSS almacenado, donde un ataque autónomo puede entregarse dentro de la propia aplicación vulnerable.
XSS reflejado en diferentes contextos
Hay muchas variedades diferentes de secuencias de comandos entre sitios reflejadas. La ubicación de los datos reflejados dentro de la respuesta de la aplicación determina qué tipo de carga útil se requiere para explotarla y también podría afectar el impacto de la vulnerabilidad.
Además, si la aplicación realiza alguna validación u otro procesamiento en los datos enviados antes de que se reflejen, esto generalmente afectará qué tipo de carga XSS se necesita.
Cómo encontrar y probar vulnerabilidades XSS reflejadas
La gran mayoría de las vulnerabilidades de secuencias de comandos entre sitios reflejadas se pueden encontrar de manera rápida y confiable utilizando el escáner de vulnerabilidades web de Burp Suite .
La prueba de vulnerabilidades XSS reflejadas manualmente implica los siguientes pasos:
- Pruebe cada punto de entrada. Pruebe por separado cada punto de entrada de datos dentro de las solicitudes HTTP de la aplicación. Esto incluye parámetros u otros datos dentro de la cadena de consulta de URL y el cuerpo del mensaje, y la ruta del archivo de URL. También incluye encabezados HTTP, aunque el comportamiento similar a XSS que solo se puede activar a través de ciertos encabezados HTTP puede no ser explotable en la práctica.
- Envíe valores alfanuméricos aleatorios. Para cada punto de entrada, envíe un valor aleatorio único y determine si el valor se refleja en la respuesta. El valor debe diseñarse para sobrevivir a la mayoría de las validaciones de entrada, por lo que debe ser bastante corto y contener solo caracteres alfanuméricos. Pero debe ser lo suficientemente largo para que las coincidencias accidentales dentro de la respuesta sean muy poco probables. Normalmente, lo ideal es un valor alfanumérico aleatorio de alrededor de 8 caracteres. Puede usar las cargas útiles de números de Burp Intruder [https://portswigger.net/burp/documentation/desktop/tools/intruder/payloads/types#numbers] con valores hexadecimales generados aleatoriamente para generar valores aleatorios adecuados. Y puede usar la opción de carga útil grep de Burp Intruder para marcar automáticamente las respuestas que contienen el valor enviado.
- Determinar el contexto de reflexión. Para cada ubicación dentro de la respuesta donde se refleja el valor aleatorio, determine su contexto. Esto podría estar en el texto entre etiquetas HTML, dentro de un atributo de etiqueta que podría estar entre comillas, dentro de una cadena JavaScript, etc.
- Probar una carga útil candidata. En función del contexto de la reflexión, pruebe una carga útil XSS candidata inicial que activará la ejecución de JavaScript si se refleja sin modificaciones en la respuesta. La forma más fácil de probar las cargas útiles es enviar la solicitud a Burp Repeater, modificar la solicitud para insertar la carga útil candidata, emitir la solicitud y luego revisar la respuesta para ver si la carga útil funcionó. Una forma eficiente de trabajar es dejar el valor aleatorio original en la solicitud y colocar la carga útil XSS candidata antes o después. Luego establezca el valor aleatorio como el término de búsqueda en la vista de respuesta de Burp Repeater. Burp resaltará cada ubicación donde aparece el término de búsqueda, permitiéndole localizar rápidamente el reflejo.
- Pruebe cargas útiles alternativas. Si la carga útil XSS candidata fue modificada por la aplicación, o bloqueada por completo, entonces deberá probar cargas útiles y técnicas alternativas que podrían generar un ataque XSS funcional según el contexto de la reflexión y el tipo de validación de entrada que se está realizando. Para obtener más detalles, consulte contextos de secuencias de comandos entre sitios
- Pruebe el ataque en un navegador. Finalmente, si tiene éxito en encontrar una carga útil que parece funcionar dentro de Burp Repeater, transfiera el ataque a un navegador real (pegando la URL en la barra de direcciones o modificando la solicitud en la vista de intercepción de Burp Proxy, y vea si el inyectado De hecho, JavaScript se ejecuta. A menudo, es mejor ejecutar un JavaScript simple como
alert(document.domain)
el que activará una ventana emergente visible dentro del navegador si el ataque tiene éxito.
Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!
Preguntas frecuentes sobre secuencias de comandos entre sitios reflejadas
¿Cuál es la diferencia entre XSS reflejado y XSS almacenado ? El XSS reflejado surge cuando una aplicación toma alguna información de una solicitud HTTP y la integra en la respuesta inmediata de una manera no segura. Con XSS almacenado, la aplicación almacena la entrada y la integra en una respuesta posterior de forma no segura.
¿Cuál es la diferencia entre XSS reflejado y XSS propio? Auto-XSS implica un comportamiento de aplicación similar al XSS reflejado regular, sin embargo, no se puede activar de manera normal a través de una URL diseñada o una solicitud entre dominios. En cambio, la vulnerabilidad solo se activa si la propia víctima envía la carga útil XSS desde su navegador. Lanzar un autoataque XSS normalmente implica diseñar socialmente a la víctima para que pegue alguna entrada proporcionada por el atacante en su navegador. Como tal, normalmente se considera un problema cojo y de bajo impacto.
Si te ha gustado, ¡compártelo con tus amigos!