X-Frame-Options : ALLOW-FROM dans firefox et chrome

Question

Je suis en train de mettre en place un "pass-through" pour X-Frame-Options de laisser un site partenaire envelopper le site de mon employeur dans un iframe, comme dans cet article : http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

(diviser les URLs pour les afficher)

En bref, la page de notre partenaire comporte une iframe avec une URL contre notre domaine. Pour toute page de notre domaine, ils ajouteront un argument url spécial comme &@mykey=topleveldomain.com qui nous indique quel est le domaine de premier niveau de la page.

Nos filtres récupèrent le TLD du partenaire, s'il est fourni, à partir de l'URL, et le valident par rapport à une liste blanche. S'il figure sur la liste, nous envoyons l'adresse de l'utilisateur. X-Frame-Options en-tête avec valeur ALLOW-FROM topleveldomain.com (et ajouter un cookie pour les clics futurs). S'il n'est pas sur notre liste blanche, nous envoyons SAMEORIGIN o DENY .

Le problème, c'est qu'on dirait qu'on envoie ALLOW-FROM domain aboutit à une absence totale de résultat pour les derniers Firefox et Google Chrome. IE8, au moins, semble implémenter correctement ALLOW-FROM .

Consultez cette page : http://www.enhanceie.com/test/clickjack . Juste après la 5e boîte (sur 5) qui "devrait afficher du contenu", se trouve une boîte qui ne devrait PAS afficher de contenu, mais qui le fait. Dans ce cas, la page dans l'iframe envoie X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com un TLD résolument différent de http://www.enhanceie.com . Pourtant, le cadre affiche toujours du contenu.

Avez-vous une idée de ce que X-Frame-Options est véritablement mis en œuvre avec ALLOW-FROM sur les différents navigateurs (de bureau) ? La syntaxe a peut-être changé ?

Quelques liens d'intérêt :

• Draft rfc on x-frame-options : https://datatracker.ietf.org/doc/html/draft-gondrom-frame-options-01
• Article de developer.mozilla traitant de l'en-tête comme un en-tête à deux options (sameorigin ou deny). https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
• le blog msdn qui a initié tout ça : 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 allow-from origin http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

Answer 1

ALLOW-FROM n'est pas pris en charge par 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 pour créer un en-tête personnalisé et l'envoyer avec les données correctes, ne pouvez-vous pas simplement exclure l'en-tête lorsque vous détectez qu'il provient d'un partenaire valide et ajouter DENY à toutes les autres requêtes ? Je ne vois pas l'avantage de AllowFrom lorsque vous construisez déjà la logique de manière dynamique.

Answer 2

J'ai posté cette question et n'ai jamais vu les réactions (qui sont arrivées plusieurs mois après, semble-t-il :).

Comme Kinlan l'a mentionné, ALLOW-FROM n'est pas pris en charge par tous les navigateurs en tant que valeur X-Frame-Options.

La solution consistait à créer des branches en fonction du type de navigateur. Pour IE, le navire X-Frame-Options . Pour tous les autres, le navire X-Content-Security-Policy (Politique de sécurité) .

J'espère que cela vous aidera, et je suis désolé d'avoir mis si longtemps à fermer la boucle !

Answer 3

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 de la réponse HTTP.
Notez que cela suppose que vous avez vérifié sur le serveur si refAuth est autorisé ou non.
Notez également que vous devez procéder à la détection du navigateur afin d'éviter d'ajouter la balise allow-from pour Chrome (erreur de sortie sur la console).

Pour plus de détails, voir ma réponse ici.