¿Es Clickjacking una vulnerabilidad de seguridad real?

31

Según tengo entendido, así es como un atacante explotaría el clickjacking:

  1. Cree un nuevo sitio web malwaresite.com que incluya mi sitio en un marco, pero superponga los campos o botones de entrada maliciosos sobre los elementos HTML de mi sitio.
  2. Envíe correos electrónicos de suplantación de identidad (phishing) para que los usuarios hagan clic en el enlace que va a malwaresite.com en lugar de a mi sitio (o utilice alguna otra técnica para distribuir el enlace de suplantación de identidad).
  3. Los usuarios ingresan datos o hacen clic en los elementos maliciosos.
  4. Beneficio

Los usuarios con experiencia no harían clic en el enlace o se darían cuenta de que la barra de direcciones es incorrecta. Sin embargo, muchas personas probablemente no se darían cuenta.

Mi pregunta es la siguiente: ¿no puede el atacante lograr lo mismo al utilizar malwaresite.com como proxy inverso? Todos los pasos anteriores serían los mismos, excepto que malwaresite.com reenviaría las solicitudes a mi sitio y luego insertaría una etiqueta <script> adicional en la respuesta HTML para ejecutar el código malicioso y agregar los elementos HTML maliciosos. El encabezado X-FRAME-OPTIONS no ayudaría en ese caso porque no hay marcos (y el proxy inverso puede eliminarlo de todos modos).

El ataque se basa en que el usuario no comprueba la barra de direcciones, por lo que si el atacante puede implementar el mismo ataque de una manera diferente que no pueda ser derrotado, ¿por qué molestarse con X-FRAME-OPTIONS u otras protecciones de clickjacking?

    
pregunta Nathan 23.03.2015 - 05:32
fuente

1 respuesta

49

Esta es una pregunta muy interesante.

En primer lugar, comencemos con su escenario: un usuario que visita el sitio web www.evil.com , que es un proxy inverso que carga www.good.com y modifica su contenido. ¡Felicitaciones ! Acabas de reinventar un ataque MiTM clásico, pero muy malo. Visitar evil.com significa que su navegador no enviará good.com cookies, lo que significa que su proxy inverso no podrá actuar en nombre del usuario. Para solucionar este problema, ahora tendrá que engañar al usuario para que inicie sesión en su proxy inverso con su good.com . ¡Felicitaciones ! Has reinventado un ataque con una página de inicio falsa.

El escenario que estás describiendo no tiene nada que ver con el clickjacking, y en realidad empleamos la protección del clickjacking por una razón muy diferente: con el clickjacking, un atacante engañaría a un usuario autenticado para realizar alguna acción. Incluso si el usuario está visitando evil.com , a diferencia de su escenario propuesto con un proxy inverso, su solicitud todavía se envía a good.com junto con las cookies que contienen su ID de sesión. Por lo tanto, la acción se realizará dentro de la sesión del usuario autenticado.

¿Le suena familiar? Sí, así es como funciona un ataque CSRF , pero la única diferencia es que, con CSRF, la acción se realiza mediante programación ... excepto por una pequeña cosa: Clickjacking anula los mecanismos anti-CSRF. Con clickjacking, la acción se realiza dentro del navegador del usuario, por el propio usuario y dentro de la página legítima (cargada dentro de iFrame).

En resumen: su ataque propuesto es ciertamente plausible, pero usamos el anti-clickjacking para derrotar ataques completamente diferentes. Para eso, sí, el clickjacking es, de hecho, una preocupación de seguridad real y distinta.

    
respondido por el Adi 23.03.2015 - 06:06
fuente

Lea otras preguntas en las etiquetas