it-swarm-es.com

Guión framebusting

Se sabe comúnmente que cargar su sitio dentro de un marco en otro sitio, puede potencialmente exponer su sitio a todo tipo de males, y en general no es una buena idea si tiene datos sensibles para proteger.
Por lo tanto, se acercaron los scripts Framebusting, generalmente un script simple que se ejecuta a medida que se carga el sitio; Si está en un marco, se vuelve a cargar sin marcos.
Por lo general, algo simple a lo largo de estas líneas:

if (top != self) 
    top.location.replace(location);

Ahora, si está en un sitio público, como el foro, o el sitio de redes sociales, donde es común publicar enlaces y que se muestren en un marco, es posible que desee modificar su sitio (si tiene algo sensible allí , son los usuarios de inicio de sesión, etc.), fuera de los marcos de las redes sociales. Pero tampoco desea interrumpir la experiencia del usuario, y hacer que piensen que el sitio al que están vinculados es sospechoso ... para que se sienta tentado a darles una ventana emergente para informarles lo que está pasando, pero eso Podría simplemente asustarlos aún más ...

Entonces, ¿cuáles crees que sería la mejor solución general, considerando la totalidad de contexto, riesgos y consecuencias, y evitando "teatro de seguridad"?

  • Dejar el sitio dentro de un marco
  • Framebust silenciosamente
  • Proporcionar una ventana emergente, solo para notificar al usuario. ¿Qué está pasando?
  • Proporcione una ventana emergente al usuario con la opción de cancelar

PD El sitio era ESTE SITIO , y encontré esto al publicar el sitio a numerosos grupos relacionados con la seguridad en LinkedIn después de que comenzó la beta pública (¿por qué no? ;)), habiendo recibido respuestas negativas de SOAM ... resulta que se retira, se va a la opción 3 - Popup con No opción para cancelar. Cruzado como un error a meta ....

5
AviD

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

Recientemente se encontró con una pregunta bastante similar aquí: https://stackoverflow.com/questions/958997/Frame-Buster-Buster-Buster-Code-Needed . Dicho, donde se dice que solicite al usuario una explicación breve de lo que está sucediendo. No puede estar en desacuerdo, la explicación más simple, mejor para la comprensión del usuario, simplemente tenga cuidado de no perder detalles tocando la privacidad de los usuarios. Con los detalles dados, el usuario tiene que pensar por sí mismo qué no está asustado.

Y OWASP tiene un buen papel de investigación sobre este tema: http://www.owasp.org/images/0/0e/owasp_appsec_research_2010_busting_frame_busting_by_frame_busting_by_rydstedt.pdf

5
anonymous

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

Si realmente quieres buscar marcos, sugeriría una solución no obstruida. Use el código Framebust regular, tal vez en conjunto con el encabezado HTTP Opciones X-Frame-Opciones , y proporcione una nota resaltada en la página en lugar de una ventana emergente.


Un sidenote: 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 política de origen mismo. Muchos hacks se basan en pasar por alto esto, al inyectar el código en otros sitios, etc. Clickjacking está relacionado, pero en lugar de usar código para realizar una función en el otro sitio, la página de ataque truca al usuario al hacer clic en algún lugar.

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 donde el código pueda hacer casi cualquier cosa que el usuario pueda, y en su lugar se basará en los tokens de seguridad. Claro, un guión de ataque podría enviar un formulario para eliminar una publicación, pero sin la identificación y contraseña de la sesión correcta, sería ignorado. Esto permitiría aplicaciones mucho más interesantes como mashups, agregadores de contenido solo de cliente, etc. Por supuesto que es demasiado tarde para cambiar la web a un modelo de seguridad de este tipo.

Estoy escribiendo esto para motivar mi consejo: incluso sin confiar en la separación forzada por el navegador (por ejemplo, Framebusting) es posible escribir sitios seguros donde el usuario autoriza cada acción. No haga que su seguridad se convierta en no marcos, sino que asuma que su sitio está enmarcado, el SOP está comprometido y el sitio de encuadre puede presionar los botones (con o sin instrumentalizar al usuario).

3
jdm