web-dev-qa-db-fra.com

X-Frame-Options ne fonctionne pas IIS web.config

Notre site n'est actuellement pas protégé contre le clickjacking, alors je suis allé dans le fichier web.config et j'ai ajouté

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="X-Frame-Options" value="DENY" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

C'est un code très simple. Mon problème est que cela ne fonctionne tout simplement pas. Les questions que j'ai sont:

  1. Est-il possible pour moi de voir si le X-Frame-Options est dans la réponse en-tête? Je l'ai cherché avec httpfox et je n'ai rien obtenu. Je ne peux donc pas vérifier si le web.config met effectivement des éléments dans l'en-tête.
  2. Pourquoi ça ne marche pas? Que puis-je faire pour tester ou avancer? 

J'ai essayé de l'ajouter dans Global.asax dans la méthode Application_Start, mais je n'arrive pas à "toucher" cette méthode lorsque je débogue; il ne frappe pas les points d'arrêt. 

private void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    HttpContext.Current.Response.AddHeader("x-frame-options", "DENY");

    LogHelper.Info("Cost of Care Web Application Starting");
}

Je voudrais ajouter que j'ai essayé de l'ajouter directement dans la balise head et que j'ai également essayé de l'ajouter dans une balise meta, comme 

<meta http-equiv="X-Frame-Options" content="deny">
iisx-frame-options
16
Moi Hawk

Puisque mes commentaires ont répondu à la question, voici le résultat final:

Pour une raison quelconque, configurer X-Frame-Options dans web.config ne semble pas fonctionner, même si la documentation donne l’impression qu’elle le devrait.

Un moyen facile de contourner le problème consiste à définir les en-têtes manuellement à l'aide de:

Response.AddHeader("X-Frame-Options", "DENY");

Si vous avez besoin de cet ensemble pour chaque demande sans exception, vous pouvez ajouter le Application_BeginRequest à Global.asax:

protected void Application_BeginRequest()
{
    Response.AddHeader("X-Frame-Options", "DENY");
}
18
siva.k

L'en-tête X-Frame-Options peut être utilisé pour contrôler si une page peut être placée dans un IFRAME. Comme la technique Framesniffing repose sur le fait de pouvoir placer le site victime dans un IFRAME, une application Web peut se protéger en envoyant un en-tête X-Frame-Options approprié.

Pour configurer IIS afin d'ajouter un en-tête X-Frame-Options à toutes les réponses pour un site donné, procédez comme suit:

  1. Ouvrez le Gestionnaire des services Internet (IIS).
  2. Dans le volet Connexions situé à gauche, développez le dossier Sites et sélectionnez le site que vous souhaitez protéger.
  3. Double-cliquez sur l'icône HTTP Response Headers dans la liste des fonctionnalités au milieu .  enter image description here
  4. Dans le volet Actions situé à droite, cliquez sur Ajouter.
  5. Dans la boîte de dialogue qui apparaît, tapez X-Frame-Options dans le champ Nom, puis SAMEORIGIN ou DENY dans le champ Valeur .  enter image description here
  6. Cliquez sur OK pour enregistrer vos modifications.
15
Voltur

La réponse de siva.k ne fonctionne pas avec MVC5 car l'en-tête est généré deux fois ici. Le code suivant devrait fonctionner:

protected void Application_Start()
{
  //  MVC5 generates the "X-Frame-Options SAMEORIGIN" header by default, the following line disables the default behaviour
  System.Web.Helpers.AntiForgeryConfig.SuppressXFrameOptionsHeader = true;
}

protected void Application_BeginRequest() 
{
  Response.AddHeader("X-Frame-Options", "DENY");
}

Le drapeau SuppressXFrameOptionsHeader a été mentionné ici: https://stackoverflow.com/a/20262211/3936440

10
ViRuSTriNiTy

Voici une autre chose à considérer: 

Si vous avez des projets principaux et d'interface utilisateur distincts (ce qui est très courant pour les sites basés sur REST), assurez-vous de placer X-Frame-Options dans l'interface utilisateur web.config. Votre API autorise probablement les appels entre sites. Il n’a donc aucun sens d’ajouter l’en-tête à votre projet d’API.

3
MarzSocks
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Content-Security-Policy" value="default-src: https:; frame-ancestors 'self' X-Frame-Options: SAMEORIGIN" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

Votre entrée web.config doit être soumise à politique de sécurité du contenu pour pouvoir utiliser le codage actuel non amorti auparavant. La valeur sous la stratégie de sécurité du contenu de value="default-src: https: est propre à votre site Web. 

Le contenu qui compte est ce qui vient après 'value = "default-src: https:' mais surtout, il est contenu dans la politique de sécurité du contenu.

1
Brian Kunick

J'ai constaté que certains types de fichiers (fichiers .asp et .htm) obtenaient l'en-tête X-Frame-Options ajouté par ce mécanisme, contrairement à d'autres (.js). À l'aide de l'utilitaire d'administration IIS, j'ai supprimé l'en-tête du niveau de l'application et l'a ajouté au niveau du serveur. Tous les fichiers obtenaient l'en-tête ajouté.

1
BlueMonkMN