X-Frame-Options: autoriser-à partir de firefox et chrome
j'implémente un "pass-through "pour X-Frame-Options pour laisser un site partenaire envelopper le site de mon employeur dans une iframe, comme dans cet article: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(fractionnement URL de post)
en un mot, la page de notre partenaire a une iframe avec une URL contre notre domaine.
Pour n'importe quelle page de notre domaine, ils ajouteront un spécial argument d'url comme &@mykey=topleveldomain.com , nous disant ce qu'est le domaine de premier niveau de la page.
nos filtres récupèrent le TLD partenaire, s'il est fourni, à partir de L'URL, et le valident par rapport à une liste blanche. Si c'est sur la liste, nous expédions l'en-tête X-Frame-Options avec la valeur ALLOW-FROM topleveldomain.com (et Ajouter un cookie pour les clics futurs). Si ce n'est pas sur notre liste blanche, Nous expédions SAMEORIGIN ou DENY .
le problème est qu'il semble que l'envoi de ALLOW-FROM domain se solde par un non-op dans l'ensemble pour le dernier Firefox et Google Chrome. IE8, du moins, semble appliquer correctement ALLOW-FROM .
consultez cette page: http://www.enhanceie.com/test/clickjack . Juste après la 5ème (de 5) boîtes que "devrait montrer le contenu", est une boîte qui ne devrait pas montrer le contenu, mais qui est. Dans ce cas , la page dans l'iframe envoie X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com , un TLD décidément différent de http://www.enhanceie.com . Pourtant, l'image affiche le contenu.
une idée à savoir si X-Frame-Options est vraiment mis en œuvre avec ALLOW-FROM à travers les navigateurs (de bureau) pertinents? Peut-être que la syntaxe a changé?
Quelques liens d'intérêt:
- Draft rfc on x-frame-options: http://tools.ietf.org/html/draft-gondrom-frame-options-01
- développeur.article de mozilla discutant de l'en-tête comme une option 2 l'en-tête (sameorigin ou de refuser). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
- msdn blog qui a initié le tout: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
- msdn blog qui parle de 3 valeurs: ajouter autoriser-d'origine http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
3 réponses
ALLOW-FROM n'est pas supporté dans Chrome ou Safari. Voir L'article de MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
vous faites déjà le travail de faire un en-tête personnalisé et l'envoyer avec les données correctes, pouvez-vous non seulement exclure l'en-tête lorsque vous détectez qu'il est d'un partenaire valide et ajouter DENY à toutes les autres requêtes? Je ne vois pas l'avantage de Allow from quand vous êtes déjà en train de construire la logique jusqu'?
j'ai posté cette question et je n'ai jamais vu le feedback (qui est venu dans plusieurs mois après, il semble :).
comme Kinlan l'a mentionné, ALLOW-FROM n'est pas pris en charge dans tous les navigateurs en tant que valeur X-Frame-Options.
la solution était de se connecter en fonction du type de navigateur. Pour IE, ship X-Frame-Options . Pour tous les autres, ship X-Content-Security-Policy .
espérons que cela aide, et désolé pour avoir mis si longtemps à boucler la boucle!
pour Chrome, au lieu de
response.AppendHeader("X-Frame-Options", "ALLOW-FROM " + host);
vous devez ajouter 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);
aux en-têtes HTTP-response.
Notez que cela suppose que vous avez vérifié sur le serveur si refAuth est autorisé ou non.
Et aussi, notez que vous devez faire une détection de navigateur pour éviter d'ajouter l'en-tête allow-from pour Chrome (erreur de sortie sur console).
pour de détails, voir ma réponse ici.