¿Proteger contra clickjacking pero permitir el enmarcado en el dominio?

3

Me gustaría proteger contra el clickjacking usando Opciones de X-Frame , pero ocasionalmente enmarcamos contenido seguro en la versión insegura de nuestro sitio 1 :

Dado que parece que solo Firefox actualmente admite la forma ALLOW-FROM del encabezado, estoy considerando el condicionamiento del encabezado:

  • De manera predeterminada, incluye X-Frame-Options.
  • Si su referencia es ^(.*\.)?example.com$ , deje el encabezado fuera.

Parece que esto funcionaría y falla: si el navegador de alguien no envía un referente o un firewall corporativo lo elimina, no nos pagan (lo cual es malo), pero nuestro contenido puede nunca se debe enmarcar en sitios de terceros (lo que sería peor).

¿Cómo funcionaría esta estrategia en el mundo real?

1 Históricamente, algunos de nuestros socios publicitarios no han admitido la publicación de anuncios a través de HTTPS. Estamos investigando si esto ha cambiado.

EDIT : para aclarar, solo anidamos un iframe seguro en una página insegura en un caso: un usuario con publicidad que compra algo por primera vez en línea. Actualmente no podemos ofrecer todo el sitio a través de HTTPS para esos usuarios y no queremos enviarlos a una página separada o abrir una ventana emergente.

Los usuarios sin publicidad obtienen HTTPS todo el tiempo, y también estamos investigando la posibilidad de publicar anuncios a través de HTTPS.

    
pregunta s4y 18.12.2014 - 00:11
fuente

1 respuesta

2

Primero, aconsejaría simplificar el problema eliminando el contenido seguro que se sirve en un marco.

Noesunaexcavacióncontraustedosuorganización,peroestamostratandodeentrenaralmundonoparaqueconfíeenformularioscomoelqueproporcionóunaimagen.Séqueestonoespartedesupregunta,perounaimagendeTransacciónseguranoesunsustitutoparaesecertificadohttps.

Sisussociosexternosnotienenlanecesidaddefuncionarcomounportalparasucontenidoseguro,eliminaresaposibilidadsimplificaríasuproblema.Implementesinexcepciónexcepcionesyhagaclicparasucontenidoseguro.RealicelapáginacompletacomoHTTPS,nosolounformularioounmarco.Sialguienusamipuntodeaccesowifigratuitoenunaeropuerto,puedocargarfácilmentetodoelformularioomarcoyreemplazarloconelmíoquepareceidéntico,completoconlaimagendeTransacciónsegura.

Devueltaalpunto,conlaeliminacióndelcontenidoseguroquesimplificaelproblema,loquequedaesunproblemadecompatibilidaddelnavegadorconX-Frame-Options.

Hayuna sobre el desbordamiento de pila que discute esto , pero no parece resolver realmente el problema, pero sí responde a la pregunta: La compatibilidad del navegador sigue siendo un problema.

Otra cosa que podría considerar, he hecho un trabajo con porthole.js antes para la comunicación entre marcos y una Una de las cosas en las que me hizo pensar es tener la capacidad de que un marco secundario valide a su principal, y de que el primario valide el marco secundario.

Puede comprobar rápidamente la compatibilidad de Portus visitando su sitio de demostración con los navegadores que le interesa apoyar.

Además, puede hacer que sus socios se identifiquen con una cadena de consulta.

<iframe src="www.site.com/?partner=3tqdHB"></iframe>

Luego, cuando su detección de click-jacking detecte una ventana primaria, verifique que exista el parámetro de cadena de consulta adecuado. Si lo hace, desafía al marco principal para que demuestre su identidad, enviando un nonce.

El marco principal podría usar el elemento proporcionado con su clave para demostrar su identidad.

Si todo funciona, no ejecute su script kill, de lo contrario, ejecute el script kill.

    
respondido por el Andrew Hoffman 18.12.2014 - 16:55
fuente

Lea otras preguntas en las etiquetas