¿Cómo hacen los hackers para que la víctima acceda a una URL de ataque XSS?

  

el usuario realizó algunas acciones que no hará como de costumbre

Hacer clic en un enlace parece ser una acción habitual para la mayoría de los usuarios.

Ver, por ejemplo, este estudio , en el que el 56% de los usuarios hizo clic en los enlaces de los correos electrónicos de un remitente desconocido, y el 40% hizo clic en los enlaces enviados a través de Facebook (a pesar de que el 78% conoce el posible peligro). El 50% dijo que no hicieron clic en el enlace porque no conocían al remitente.

Eso ya es una tasa de éxito impresionante. Si la víctima conoce al atacante, o si el atacante falsifica la identidad de alguien que conoce, esta tasa podría aumentar aún más.

En las redes sociales, el XSS reflejado también puede ser wormable. Además de la acción maliciosa, el script inyectado podría enviar mensajes con el enlace a todos los amigos de la víctima (algo como esto, por ejemplo, sucedió con Twitter ).

Además del correo electrónico, los enlaces también podrían distribuirse en foros, blogs, rastreadores de problemas, etc. Esto, por ejemplo, le sucedió a Apache .

Eso es lo que siempre me he preguntado, y cuando preguntaba, generalmente me decían que "los usuarios no se preocupan y hacen clic en todo". Lo que se dice de esa manera hace que parezca que el XSS reflejado no es realmente una vulnerabilidad del software, sino una vulnerabilidad de los usuarios. Todo esto me sonó extraño porque soy el tipo de persona que normalmente verifica la vista previa del enlace (que se mueve con el mouse en el enlace en el navegador), y si alguien me dice que haga clic en sobre esta pregunta en StackExchange y veo el formato extraño (ver la ruta), no voy a hacer clic.

Sin embargo, debo decir que hay maneras de hacer que el XSS reflejado sea más peligroso de lo que parece al principio. Considere los siguientes puntos:

• Clics automáticos, redirecciones o trucos similares: no tiene que hacer clic, todo lo que tiene que hacer es aterrizar en un sitio web malicioso que redireccionará automáticamente al sitio web de destino y ejecutará el javascript malicioso. Si ha iniciado sesión en el sitio web de destino, el atacante le hará ejecutar un javascript arbitrario y realizar acciones maliciosas (enviar o eliminar cosas, etc.)
• Sitios web que normalmente tienen URL largas o complejas (no fáciles de usar) y que el usuario tiende a confiar de todos modos. Tiendo a ver esto en Amazon, los enlaces son ilegibles de todos modos.
• Los navegadores que no te permiten ver una vista previa con facilidad, como en los navegadores móviles u otro software donde no es tan simple como flotar. Debo admitir que no me tomo el tiempo para verificar enlaces en dispositivos móviles, solo hago tapping, aunque en dispositivos móviles solo trato de usar una selección restringida de sitios web de confianza.
• El atacante conoce a la víctima, sabe cómo convencerla de que haga clic en un enlace o visite una página y, en algunos casos, la víctima puede incluso confiar en el atacante. Un correo electrónico aleatorio de un desconocido no es lo mismo que un mensaje privado de Facebook de un conocido (malicioso).
• Boobs and lols: las imágenes con boobs, lolcats, etc. pueden hacer que pierdas tu conciencia temporalmente, y es posible que sientas que debes hacer clic en él al mismo tiempo que es una ley de la física.

Entonces, como puede ver, los riesgos asociados con el XSS reflejado pueden variar mucho, dependiendo del usuario, la confianza otorgada al sitio web afectado, las posibles acciones en el sitio web de destino, etc. Sin embargo, aún existe una vulnerabilidad de software en en cualquier caso, porque por definición permite la ejecución arbitraria de javascript al explotar una debilidad en el saneamiento de entrada.

El ejemplo que has dado es muy trivial. Hay muchas aplicaciones que tienen docenas de parámetros GET en la URL que se comparte. Todo lo que necesita el atacante es que uno de estos sea vulnerable al XSS reflejado para que esto tenga éxito. Si el enlace que alguien espera es largo y complejo, y lo que obtienen es largo y complejo, es posible que no analicen cada parámetro.

Además, podrían usar un acortador de URL.

Hay dos tipos principales de XSS, reflectivo y persistente. El XSS persistente es cuando se almacena en el servidor, afectando a otros usuarios, mientras que reflectivo no se almacena, pero puede afectar a otros usuarios.

Un método que he visto es almacenar algo como una redirección en un comentario que tiene una mala limpieza. De esta manera, el código se almacena en el lado del servidor, y cuando alguien solicita la página, el código se carga junto con los comentarios, que luego activan el bloque de código. Esto puede redirigir a la víctima al sitio web de los atacantes, donde podrían estar ocurriendo otras cosas maliciosas, por ejemplo. Páginas de inicio de sesión falsas para recolectores de credenciales, pilas de anuncios, etc.

Si necesita más información, hágamelo saber, puedo editar cuando vuelva a la PC y agregar más detalles.

EDITAR: Por ejemplo, si un sitio era susceptible a este tipo de ataque, se podría dejar un comentario que redirigiera a todos los usuarios que visitaron esa página a un sitio nuevo, este sitio podría ser una copia casi idéntica al sitio original, diseñado para brindarle para iniciar sesión de nuevo, y luego robar credenciales. Debido a que las personas tienden a usar las mismas contraseñas en varios sitios, estas credenciales podrían usarse para iniciar sesión en otro lugar, etc.

Básicamente

Para algunos ataques, la víctima debe visitar la página del atacante. Hay un par de maneras de hacer eso:

• Phishing. Envíe a la víctima un correo electrónico, una página de Facebook, una invitación a LinkedIn con un enlace que pretende ser otra cosa. La tasa de éxito de esto depende de cuánto esfuerzo se dedique a la campaña, pero las tasas de éxito superiores al 50% no son infrecuentes. Especialmente porque el nombre del dominio coincide: intenta engañar a los usuarios de somegoodsite.com para que hagan clic en el enlace somegoodsite.com, y esto generalmente se puede confiar.
• Inclusión desde dentro del propio sitio. A veces el sitio permite agregar contenido de usuario. Si el atacante puede agregar un iframe a su página de perfil, cualquier persona que acceda a su perfil será atacada. Sin embargo, es bastante raro poder agregar un iframe a cualquier sitio.
• ataque del hombre en el medio. En un ataque de hombre en el medio, el atacante puede modificar los datos sin cifrar. Incluso si somegoodsite.com usa HTTPS, el atacante puede inyectar un iframe en una página web que no usa HTTPS y hacer que su navegador visite la URL.
• anuncios. Algunos sitios ejecutan anuncios intrusivos que cargan una página en un iframe o incluso en una nueva ventana. A veces recibo esto con el mensaje de que he ganado un iPhone gratis, pero también puedes ejecutarlos con una carga útil XSS. Sin embargo, creo que los sitios que permiten publicidades tan intrusivos son bastante raros.

Cada vez que un desarrollador web hace esto:

<script src="someOtherDomainThanThisOne"></script>

Esa es una posible avenida para XSS. El sitio que el usuario está visitando no necesita estar comprometido en lo más mínimo, solo el sitio que aloja el script.

Por ejemplo, si soy un desarrollador web que trabaja en mi sitio web widgets.com y encuentro esta nueva y llamativa biblioteca js. En lugar de alojarlo directamente desde mi sitio, elegí la ruta no segura de incluirlo (a través de script src) de cooljslibs.com. En algún momento en el futuro, cooljslibs.com se deshace, o alguien lo piratea y compromete los archivos alojados. Ahora, widgets.com no ha sido pirateado de ninguna manera, pero debido a que está ejecutando ciegamente el código de cooljslibs.com, ha comprometido a sus usuarios y al sitio.

Esto se puede mitigar parcialmente utilizando la integridad del sub-recurso, que básicamente está forzando una comprobación de hash en el archivo de terceros. Todavía es mejor alojarlo tú mismo además de esto. Puede obtener más información al respecto aquí . ex :)

<script src="https://example.com/example-framework.js"integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
    crossorigin="anonymous"></script>

Creo que un gran ejemplo de cómo se puede utilizar un XSS en la naturaleza es la reciente violación de datos de British Airways. Como se explica en este artículo: enlace los atacantes almacenaron un javascript malicioso, reemplazando un habitual Script en la página de pago, que robaría la tarjeta de crédito introducida por el usuario. Aunque este no es un ataque XSS típico, ya que tuvieron acceso al servidor para cambiar el script, todavía es una demostración muy válida de dicho ataque.

Si puede almacenar de alguna forma algún javascript válido en un sitio web (XSS almacenado), puede robar la cookie del usuario y hacerse pasar por ese usuario y acceder a la misma información (como datos de perfil).

En cuanto al XSS reflejado, necesita hacer algo de ingeniería social y hacer que el usuario haga clic en un enlace malicioso, como han señalado otros.