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.