X-Frame-Options Permettent-à Partir de multiples domaines
J'ai un ASP.NET 4.0 IIS7.5 site dont j'ai besoin sécurisé à l'aide de la X-Frame-Options d'en-tête.
J'ai aussi besoin d'activer mes pages du site pour être iframed de mon domaine ainsi que de mon facebook app.
Actuellement, j'ai mon site configuré avec un site dirigé de:
Response.Headers.Add("X-Frame-Options", "ALLOW-FROM SAMEDOMAIN, www.facebook.com/MyFBSite")
Quand j'ai regardé mon Facebook page avec google Chrome ou Firefox de mes sites pages (en cours de iframed avec mon facebook page) sont d'affichage ok, mais sous IE9, j'obtiens l'erreur:
"cette page ne peut être affichée..." (en raison de la
X-Frame_Options
restriction).
Comment puis-je régler l' X-Frame-Options: ALLOW-FROM
pour plus d'un domaine unique?
X-FRAME-OPTION
être une nouvelle fonctionnalité semble fondamentalement viciée si un seul domaine peut être défini.
- Cela semble être une limitation connue: owasp.org/index.php/...
Vous devez vous connecter pour publier un commentaire.
X-Frame-Options
est obsolète. De MDN:L'alternative moderne est la
Content-Security-policy
en-tête, ainsi que de nombreuses autres politiques peuvent-blanc-la liste de ce que les Url sont autorisés à héberger votre page dans un cadre, à l'aide de lachâssis ancêtres
directive.frame-ancestors
prend en charge plusieurs domaines et même des caractères génériques, par exemple:Malheureusement, pour l'instant, Internet Explorer ne prend pas en charge le Contenu-de la Politique de Sécurité.
mise à JOUR: MDN a enlevé leur désapprobation commentaire. Voici un commentaire similaire de W3C du Contenu de la Politique de Sécurité de Niveau
X-Frame-Options
changé, et est moins grave maintenant. C'est un bon point qu'il est risqué d'utiliser une spécification qui n'est pas finalisé. Merci!X-Frame-Options
ne prend pas en charge plusieurs sources.De RFC 7034:
Donc,
Vous ne pouvez pas. Comme solution de contournement, vous pouvez utiliser des Url différentes pour les différents partenaires. Pour chaque URL, vous pouvez utiliser ses propres
X-Frame-Options
valeur. Par exemple:Pour
yousite.com
vous pouvez simplement utiliserX-Frame-Options: deny
.BTW, pour l'instant Chrome (et tous basé sur webkit navigateurs) ne prend pas en charge
ALLOW-FROM
déclarations à tous.ALLOW-FROM
en utilisant le lien que vous avez fourni.Comment sur une approche qui permet non seulement de multiples domaines, mais permet dynamique domaines.
Le cas d'utilisation est ici avec une application Sharepoint partie qui charge notre site à l'intérieur de Sharepoint via une iframe. Le problème est que sharepoint est dynamique sous-domaines tels que https://yoursite.sharepoint.com. Donc, pour IE, nous devons spécifier PERMETTRE DE https://.sharepoint.com
Affaire délicate, mais nous pouvons le faire connaître deux faits:
Quand un iframe charge, il ne fait que valider les X-Frame-Options sur la première demande. Une fois que l'iframe est chargé, vous pouvez naviguer à l'intérieur de l'iframe et l'en-tête n'est pas vérifié sur les demandes ultérieures.
Aussi, quand un iframe est chargé, le HTTP referer est le parent iframe url.
Vous pouvez tirer parti de ces deux faits côté serveur. En ruby, je suis en utilisant le code suivant:
Ici on peut dynamiquement permettre domaines basée sur le domaine parent. Dans ce cas, nous nous assurons que l'hôte se termine dans sharepoint.com en gardant notre site à l'abri des clickjacking.
J'aimerais entendre des commentaires sur cette approche.
/\.sharepoint\.com$/
Necromancing.
Les réponses sont incomplètes.
Tout d'abord, comme déjà dit, vous ne pouvez pas ajouter de multiples permettent d'hôtes, qui n'est pas pris en charge.
Deuxièmement, vous devez extraire dynamiquement cette valeur à partir de l'adresse HTTP référent, ce qui signifie que vous ne pouvez pas ajouter de la valeur sur le Web.config, car il n'est pas toujours la même valeur.
Il sera nécessaire de faire un navigateur de détection pour éviter l'ajout de permettre-à partir de quand le navigateur est Chrome (il se produit une erreur sur le debug console, ce qui peut rapidement remplir la console, ou d'en faire la demande lent). Cela signifie également que vous avez besoin de modifier la ASP.NET la détection du navigateur, comme il l'identifie à tort Bord de Chrome.
Cela peut être fait en ASP.NET en écrivant un HTTP-module qui s'exécute sur chaque demande, qui ajoute un http en-tête pour toute réponse, en fonction de la demande du référent. Pour Chrome, il a besoin d'ajouter du Contenu-de la Politique de Sécurité.
Vous devez vous inscrire à la context_EndRequest fonction dans le HTTP-module de fonction Init.
Ensuite, vous devez ajouter le module à votre application.
Vous pouvez soit le faire par programme Mondial.asax par substitution de la fonction Init de la HttpApplication, comme ceci:
ou vous pouvez ajouter des entrées pour le Web.config si vous n'avez pas l'application du code source:
L'entrée dans le système.le serveur web est pour IIS7+, l'autre dans le système.le web est pour IIS 6.
Notez que vous devez définir runAllManagedModulesForAllRequests de vrai, pour qu'il fonctionne correctement.
La chaîne est de type dans le format
"Namespace.Class, Assembly"
.Notez que si vous écrivez votre assemblée VB.NET au lieu de C#, visual basic crée un par défaut de l'espace de Noms pour chaque projet, de sorte que votre chaîne va ressembler
Si vous voulez éviter ce problème, écrire la DLL en C#.
Que par la MDN Spécifications,
X-Frame-Options: ALLOW-FROM
n'est pas pris en charge dans le Chrome et le soutien est inconnue du Bord et de l'Opéra.Content-Security-Policy: frame-ancestors
remplaceX-Frame-Options
(comme par cette W3 spec), maisframe-ancestors
a compatibilité limitée. Selon ces MDN Specs, il n'est pas pris en charge dans IE ou Edge.Les RFC pour le Champs de l'Entête HTTP X-Frame-Options stipule que la "AUTORISER le-champ dans le X-Frame-Options valeur d'en-tête peut ne contenir qu'un seul domaine. Plusieurs domaines ne sont pas autorisés.
Le RFC suggère un travail autour de ce problème. La solution est de spécifier le nom de domaine comme un paramètre de l'url de l'iframe src url. Le serveur qui héberge l'iframe src url peut alors vérifier le nom de domaine donné dans les paramètres de l'url. Si le nom de domaine correspond à une liste de validité des noms de domaine, le serveur peut envoyer le X-Frame-Options d'en-tête avec la valeur: "PERMETTEZ-à PARTIR du nom de domaine", d'où le nom de domaine est le nom du domaine qui est d'essayer d'intégrer le contenu à distance. Si le nom de domaine n'est pas indiquée ou n'est pas valide, alors le X-Frame-Options d'en-tête peuvent être envoyés avec la valeur: "refuser".
Strictement parlant, non, vous ne pouvez pas.
Vous pouvez toutefois spécifier
X-Frame-Options: mysite.com
et donc de permettresubdomain1.mysite.com
etsubdomain2.mysite.com
. Mais oui, c'est encore un domaine. Il arrive à être certains solution de contournement pour ce problème, mais je pense que c'est plus facile à lire que directement à la RFC spécifications: https://tools.ietf.org/html/rfc7034Il est également intéressant de souligner que le Contenu de la Politique de Sécurité (CSP) de l'en-tête
frame-ancestor
directive obsoletes X-Frame-Options. Lire la suite ici.Pas exactement le même, mais pourrait fonctionner pour certains cas: il y a une autre option
ALLOWALL
qui aura pour effet de supprimer la restriction, ce qui pourrait être une bonne chose pour les tests de pré-production environnementsJ'ai dû ajouter X-Frame-Options pour IE et le Contenu de la Politique de Sécurité pour les autres navigateurs.
J'ai donc fait quelque chose comme suit.
Une solution possible serait d'utiliser un "cadre-breaker" script comme décrit ici
Vous avez juste besoin de modifier l'instruction "if" pour vérifier votre permis de domaines.
Cette solution de contournement serait à l'abri, je pense. parce qu'avec javascript activé, vous n'aurez pas de problème de sécurité sur un site web malveillant, le cadrage de votre page.
OUI. Cette méthode a permis à de nombreux domaines.
VB.NET