Suppression / masquage / désactivation des en-têtes de réponse HTTP excessifs dans Azure / IIS7 sans UrlScan

Je dois supprimer les en- têtes excessifs (principalement pour réussir les tests de pénétration). J'ai passé du temps à rechercher des solutions qui impliquent l'exécution d'UrlScan, mais celles-ci sont lourdes car UrlScan doit être installé à chaque fois qu'une instance Azure est démarrée .

Il doit exister une bonne solution pour Azure qui n'implique pas le déploiement de programmes d'installation à partir de startup.cmd.

Je comprends que les en-têtes de réponse sont ajoutés à différents endroits :

• Serveur : ajouté par IIS.
• X-AspNet-Version : ajouté par System.Web.dll au moment de Flush dans la classe HttpResponse
• Version X-AspNetMvc : Ajouté par MvcHandler dans System.Web.dll.
• X-Powered-By : ajouté par IIS

Existe-t-il un moyen de configurer (via web.config, etc.?) IIS7 pour supprimer / masquer / désactiver les en-têtes de réponse HTTP pour éviter l'avertissement «En-têtes excessifs» sur asafaweb.com , sans créer de module IIS ou déployer des installateurs qui doivent être exécuté à chaque démarrage d'une instance Azure?

Les modifications suivantes vous permettent de supprimer ces en-têtes de réponse HTTP dans Azure sans écrire un HttpModule personnalisé.

La plupart des informations sur le net sont obsolètes et concernent UrlScan (qui a depuis été intégré dans IIS7, mais avec l' RemoveServerHeader=1option supprimée). Voici la solution la plus soignée que j'ai trouvée (grâce à ce blog , à cette réponse et à ce blog combiné).

Pour supprimer Server , accédez à Global.asax, recherchez / créez l' Application_PreSendRequestHeadersévénement et ajoutez ce qui suit (grâce à BK et à ce blog, cela n'échouera pas non plus sur Cassini / local dev):

Modifié en avril 2014: vous pouvez utiliser les événements PreSendRequestHeaders et PreSendRequestContext avec des modules IIS natifs, mais ne les utilisez pas avec des modules gérés qui implémentent IHttpModule. La définition de ces propriétés peut entraîner des problèmes avec les demandes asynchrones . La version correcte consiste à utiliser l'événement BeginRequest.

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        var application = sender as HttpApplication;
        if (application != null && application.Context != null)
        {
            application.Context.Response.Headers.Remove("Server");
        }
    }

Pour supprimer X-AspNet-Version , dans le web.config, recherchez / créez <system.web>et ajoutez:

  <system.web>
    <httpRuntime enableVersionHeader="false" />

    ...

Pour supprimer X-AspNetMvc-Version , accédez à Global.asax, recherchez / créez l' Application_Startévénement et ajoutez une ligne comme suit:

  protected void Application_Start()
  {
      MvcHandler.DisableMvcResponseHeader = true;
  }

Pour supprimer X-Powered-By , dans le web.config, recherchez / créez <system.webServer>et ajoutez:

  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>

    ...

MSDN publié cet article expliquant comment masquer les en-têtes sur les sites Web Azure. Vous pouvez maintenant masquer le serveur de web.config en ajoutant une entrée à system.webServer

<security>
      <requestFiltering removeServerHeader ="true" />
</security>

VS froncera les sourcils en voyant ce qui précède comme invalide. Le lien ci-dessus contient du code sous forme de photos, difficile à trouver. La version MVC est toujours masquée dans le démarrage de l'application comme ci-dessus, de même pour la version x-powered-by et .Net.

Il existe également un package sur NuGet qui vous aide à atteindre cet objectif grâce à quelques lignes de configuration et aucune modification du code: NWebsec. La documentation sur la suppression des en-têtes de version peut être trouvée ici: https://github.com/NWebsec/NWebsec/wiki/Suppressing-version-headers

C'est démo ici: http://www.nwebsec.com/HttpHeaders/VersionHeaders (dans Azure)

Avertissement: je suis le développeur du projet.

La réponse de Nick Evans est parfaite, mais ...

Si vous supprimez ces en-têtes pour des raisons de sécurité , n'oubliez pas de modifier le ASP.NET Session coockie name! Parce qu'il est plus facile de deviner la langue utilisée ou la version du serveur lorsque vous voyez ceci:

Pour changer le nom du cookie: (soyez créatif)

<system.web>
  <sessionState cookieName="PHPSESSID" />
</system.web>

En regroupant les réponses précédentes de @ giveme5minutes et @AKhooli en ce qui concerne les sites Web Azure, ainsi que quelques autres éléments que l'analyseur souhaite voir, voici les modifications que j'ai apportées pour rendre ASafaWeb satisfait d'un site Azure.

Il se plaint toujours du fait que le cookie d'en-tête d'affinité Azure n'est pas uniquement https, mais l'affinité est le type de cookie que vous voulez quand même rejouer, non?

<system.web>
    <compilation debug="false">
    <httpRuntime enableVersionHeader="false" />
    <httpCookies httpOnlyCookies="true" requireSSL="true" />    
    <customErrors mode="RemoteOnly" defaultRedirect="~/Error.aspx" />
</system.web>

<system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="X-Frame-Options" value="DENY" />
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
    <security>
      <!--removes Azure headers-->
      <requestFiltering removeServerHeader="true" />
    </security>
</system.webServer>