¿Cómo prevenir el siguiente ataque de clickjacking?

2

El atributo de Seguridad se implementó para prevenir ataques XSS en iFrames al deshabilitar cualquier JS implementado en la fuente iFrame, por lo tanto, eliminar los ataques XSS, pero también deshabilitar cualquier script de seguridad como busters de cuadros, asesinos y amp; etc.

Por ejemplo, aquí hay tres páginas:

Página de víctimas

<html>
<head>
<script type="text/javascript">
if(top != self) top.location.replace(location);
</script>
</head>
<body bgcolor="red">
<img src="kitten.jpg" width="100%" height="100%">
</body>
</html>

Esta página contiene un destructor de cuadros muy pobre, pero lo suficientemente bueno para esta demostración. En caso de que la página no sea el marco superior en su ventana, redirige la ventana a la ubicación de la página.

Página A

<html>
<body>
<center><iframe src="noIFrame.htm" border=1>    </center>
</body>
</html>

Esta página contiene un ejemplo, lo que sucede cuando el atacante simplemente agrega la página mediante iframe, sin habilitar el atributo de seguridad. El resultado de abrir esta página es un vistazo rápido a la página de los clickers y luego a la redirección del navegador a la ubicación de la página.

Página B

<html>
<body>
<center><iframe src="noIFrame.htm" security="restricted" border=1></center>
</body>
</html>

Finalmente, esta página demuestra la implementación del atributo de seguridad. El iFrame está cargado, y dado que el atributo está configurado para restringido, el script de eliminación de marcos no está redirigiendo el navegador a la ubicación de la página de las víctimas. Tenga en cuenta que este ataque solo es viable en IE8 y superior.

Ahora, suponiendo que un usuario malintencionado puede cargar archivos en el servidor web de las víctimas * (deshabilitando, a mi entender, el posible uso de X-Frame-Options), ¿cómo puede la víctima proteger su sitio web de los ataques de clicking contra sus usuarios de IE?

* Esta es una pregunta hipotética, por supuesto, si el atacante tiene acceso al dominio del servidor web, atacaría de manera diferente.

    
pregunta Boaz Tirosh 12.09.2012 - 22:19
fuente

1 respuesta

3

La única forma de evitar el clickjacking en una versión de IE demasiado antigua para admitir X-Frame-Options es hacer que la página sea dependiente de JavaScript, para que se rompa cuando se ejecuta con security="restricted" . Por ejemplo:

<style type="text/css">
   body.notframed #warning { display: none; }
   body.framed #content { display: none; }
</style>
<body class="framed">
   <script type="text/javascript">
       if (top==self)
           document.body.className= 'notframed';
   </script>
   <div id="content">
       ...
   </div>
   <div id="warning">
       This site cannot be used in a frame or with JavaScript disabled.
   </div>
</body>

Obviamente, esto tiene implicaciones de accesibilidad muy negativas. Si el sitio en cuestión ya no funciona sin JS, podría ser aceptable, pero generalmente no vale la pena.

(También demuestra la táctica de inutilizar tu página en lugar de intentar redirigir la página principal como en el framebuster "muy pobre". De hecho, la opción de redireccionamiento no puede ser segura).

No estoy seguro de a qué se refiere su último comentario: X-Frame-Options no impide la carga de archivos, pero funciona bien para protegerse contra el enmarcado desde cualquier sitio (tercero o primero), el único problema con es la falta de soporte en versiones antiguas de IE.

    
respondido por el bobince 14.09.2012 - 01:12
fuente

Lea otras preguntas en las etiquetas