ihs - X-Frame-Options: ALLOW-FROM en firefox y cromo
x-frame-options header php (3)
Estoy implementando un "paso a través" para X-Frame-Options para permitir que un sitio asociado ajuste el sitio de mi empleador en un iframe, según este artículo: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(división de URLS para publicar)
En pocas palabras, la página de nuestro socio tiene un iframe con una URL en contra de nuestro dominio. Para cualquier página de nuestro dominio, agregarán un argumento de url especial como &@mykey=topleveldomain.com , diciéndonos cuál es el dominio de nivel superior de la página.
Nuestros filtros recogen el TLD asociado, si lo hay, de la URL y lo validan con una lista blanca. Si está en la lista, enviamos el encabezado X-Frame-Options con el valor ALLOW-FROM topleveldomain.com (y agregamos una cookie para futuros clics). Si no está en nuestra lista blanca, enviamos SAMEORIGIN o DENY .
El problema es que parece enviar ALLOW-FROM domain resultados del ALLOW-FROM domain una general no operativa para los últimos Firefox y Google Chrome. IE8, al menos, parece estar implementando correctamente ALLOW-FROM .
Echa un vistazo a esta página: http://www.enhanceie.com/test/clickjack . Inmediatamente después de la quinta (de 5) casillas que "deberían mostrar contenido", hay una casilla que NO debe mostrar contenido, pero que sí lo está. En este caso, la página del iframe envía X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com , un TLD decididamente diferente de http://www.enhanceie.com . Sin embargo, el marco todavía muestra contenido.
¿Alguna idea sobre si X-Frame-Options está realmente implementado con ALLOW-FROM en navegadores relevantes (de escritorio)? Tal vez la sintaxis ha cambiado?
Algunos enlaces de interés:
- Draft rfc en x-frame-options: http://tools.ietf.org/html/draft-gondrom-frame-options-01
- Artículo developer.mozilla que analiza el encabezado como un encabezado de 2 opciones (sameorigin o deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
- msdn blog que inició todo: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
- msdn blog que habla de 3 valores: agregar origen de http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
ALLOW-FROM no es compatible con Chrome o Safari. Vea el artículo de MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
Ya está haciendo el trabajo de crear un encabezado personalizado y enviarlo con los datos correctos. ¿No puede excluir el encabezado cuando detecta que proviene de un socio válido y agregar DENY a cada otra solicitud? No veo el beneficio de AllowFrom cuando ya estás desarrollando dinámicamente la lógica?
Para Chrome, en lugar de
response.AppendHeader("X-Frame-Options", "ALLOW-FROM " + host);
necesitas agregar Content-Security-Policy
string selfAuth = System.Web.HttpContext.Current.Request.Url.Authority;
string refAuth = System.Web.HttpContext.Current.Request.UrlReferrer.Authority;
response.AppendHeader("Content-Security-Policy", "default-src ''self'' ''unsafe-inline'' ''unsafe-eval'' data: *.msecnd.net vortex.data.microsoft.com " + selfAuth + " " + refAuth);
a los encabezados de respuesta HTTP.
Tenga en cuenta que esto supone que ha comprobado en el servidor si se permite refAuth o no.
Y también, tenga en cuenta que debe hacer la detección del navegador para evitar agregar el encabezado allow-from permiso para Chrome (error de salida en la consola).
Para más detalles, mira mi respuesta aquí.
Publiqué esta pregunta y nunca vi los comentarios (que llegaron varios meses después, parece :).
Como mencionó Kinlan, ALLOW-FROM no es compatible en todos los navegadores como un valor de X-Frame-Options.
La solución fue ramificar según el tipo de navegador. Para IE, envíe X-Frame-Options . Para todos los demás, envíe X-Content-Security-Policy .
Espero que esto ayude y disculpe por tomar tanto tiempo para cerrar el ciclo.