script FrameBusting

Buena pregunta. FrameBusting es difícil de implementar correctamente y en casi todos los casos se rompe debido a razones como la incompatibilidad de los navegadores, errores o errores de los desarrolladores.

Recientemente encontré una pregunta bastante similar aquí: enlace . ¿Dónde se dice que avise al usuario con una breve explicación de lo que está sucediendo? No puede estar en desacuerdo, la explicación más sencilla: mejor para la comprensión del usuario, simplemente tenga cuidado de no perder detalles que afectan a la privacidad de los usuarios. Con los detalles dados, el usuario debe pensar por su cuenta qué hacer para no tener miedo.

Y OWASP tiene un buen trabajo de investigación sobre este tema: enlace

La solución que preferiría como usuario sería: permitir que su sitio se enmarque, pero asegúrese de que los sitios maliciosos no causen ningún daño. No continúe con la sesión del usuario desde otra pestaña si está en un marco. Considere hacer el sitio de sólo lectura en este caso. Si permite que el usuario vuelva a iniciar sesión en el marco, muestre una advertencia. Por supuesto, esto es mucho trabajo para implementar en un caso de uso raro, por lo que podría no ser práctico.

Si realmente quieres romper los marcos, te sugiero una solución discreta. Utilice el código de configuración de fotogramas normal, tal vez en conjunto con X-Frame-Options Encabezado HTTP y proporcione una nota resaltada en la página en lugar de una ventana emergente.

Una nota al margen: El modelo de seguridad HTML se basa en el hecho de que un sitio no puede hacer cosas a otros sitios. Esto nos da la misma política de origen. Muchos hacks se basan en omitir esto, inyectando código en otros sitios, etc. El secuestro de clics está relacionado, pero en lugar de usar código para realizar una función en el otro sitio, la página de ataque engaña al usuario para que haga clic en alguna parte.

Personalmente, creo que el modelo de seguridad HTML, donde los servidores confían en el navegador para mantener los scripts confinados, es conceptualmente defectuoso. Preferiría un modelo en el que el código pueda hacer casi cualquier cosa que el usuario pueda hacer, y en lugar de eso, confiaría en tokens de seguridad. Claro, un script de ataque podría enviar un formulario para eliminar una publicación, pero sin el ID de sesión y la contraseña correctos, se ignoraría. Esto permitiría aplicaciones mucho más interesantes como mashups, agregadores de contenido solo para el cliente, etc. Por supuesto, ahora es demasiado tarde para cambiar la web a ese modelo de seguridad.

Estoy escribiendo esto para motivar mi consejo: incluso sin depender de la separación impuesta por el navegador (por ejemplo, framebusting) es posible escribir sitios seguros donde el usuario autorice cada acción. No haga que su seguridad se base en no-frames, pero suponga que su sitio está enmarcado, el SOP está comprometido y el sitio de encuadre puede presionar botones (con o sin instrumentalizar al usuario).