¿Cómo “entregar” un ataque de clickjacking?

Digamos que un atacante quiere que un usuario haga clic en algo en victim.com .

Para esto, necesitan colocar un iframe en algún lugar, en cualquier lugar, donde la víctima lo vea. Realmente no importa dónde se coloca, o cómo se colocó allí.

Esto no es obligatorio, pero lo ideal es que el atacante también pueda ejecutar JavaScript aquí, ya que aumenta la posibilidad de una explotación exitosa, especialmente con ataques de varios clics (es posible "seguir" el puntero del mouse y así asegurarse de que cualquier clic haga clic en la posición deseada del sitio web de victim.com).

Estas son las formas en que puedo pensar que un atacante puede entregar un iframe a una víctima:

• El atacante secuestra un sitio web, good.com , saben que visitará su víctima. Esto puede suceder de diferentes maneras; el sitio web puede permitir la creación de iframes, o el atacante puede haber comprometido el servidor
• El atacante crea su propio sitio web, evil.com , coloca su carga de ClickJacking en él, y consigue que la víctima lo visite enviándoles un enlace.
• Correo electrónico: algunos clientes de correo electrónico pueden mostrar (un subconjunto de) el código HTML (aunque en realidad es solo una subcategoría del primer punto)
• El atacante puede colocar un iframe en victim.com . Si este es el caso, el problema probablemente se extienda más allá de ClickJacking (al menos inyección de HTML, probablemente XSS).
• El atacante puede cambiar el HTML entregado en transferencia (mitm) o en el lado del cliente y, por lo tanto, inyectar un iframe. Pero una vez más, si esto es posible, hay consecuencias mucho mayores que ClickJacking.

Este es un ejemplo muy simple de cómo podría verse una carga útil de ClickJacking:

// placed anywhere, eg http://evil.com/clickjacking.html
<div style="position: absolute; left: 50px; top: 50px; pointer-events: none;">
    Click Me!
</div>
<iframe style="opacity: 0;" height="500" width="600" scrolling="no" src="http://victim.com/vulnerable.html>
</iframe>

Por lo tanto, no es necesario que un atacante cambie el HTML de victim.com (ni en la fuente ni en el lado del cliente).