Supprimer l'en-tête de réponse du serveur IIS7

Question

Existe-t-il un moyen de supprimer l'en-tête de réponse "Server" de IIS7 ? Il existe des articles montrant que l'utilisation de HttpModules permet de réaliser la même chose. Cela sera utile si nous n'avons pas de droits d'administration sur le serveur. De plus, je ne veux pas écrire de filtre ISAPI.

J'ai des droits d'administration sur mon serveur. Je ne veux donc pas faire les choses ci-dessus. Alors, s'il vous plaît, aidez-moi à faire la même chose.

Answer 1

Ajoutez ceci à votre global.asax.cs :

protected void Application_PreSendRequestHeaders()
{
    Response.Headers.Remove("Server");
    Response.Headers.Remove("X-AspNet-Version");
    Response.Headers.Remove("X-AspNetMvc-Version");
}

Answer 2

Dans IIS7, vous devez utiliser un module HTTP. Construisez ce qui suit comme une bibliothèque de classe dans VS :

namespace StrongNamespace.HttpModules
{
  public class CustomHeaderModule : IHttpModule
  { 
    public void Init(HttpApplication context)
    {
      context.PreSendRequestHeaders += OnPreSendRequestHeaders;
    } 

    public void Dispose() { } 

    void OnPreSendRequestHeaders(object sender, EventArgs e)
    {
      HttpContext.Current.Response.Headers.Set("Server", "Box of Bolts");
    }
  }
}

Ajoutez ensuite ce qui suit à votre web.config, ou configurez-le dans IIS (si vous le configurez dans IIS, l'assemblage doit être dans le GAC).

<configuration>
  <system.webServer>
    <modules>
      <add name="CustomHeaderModule"
       type="StrongNamespace.HttpModules.CustomHeaderModule" />
    </modules>
  </system.webServer>
</configuration>

Answer 3

Dans un billet de blog, Scott Mitchell propose des solutions pour suppression des en-têtes inutiles .

Comme déjà dit ici dans d'autres réponses, pour la Server il y a l'en-tête solution de module http ou un Solution de web.config pour IIS 10+. ou vous pouvez utiliser URLRewrite à la place pour l'effacer .

Pour cette Server la solution la plus pratique pour une installation à jour (IIS 10 +) est d'utiliser la fonction removeServerHeader dans le web.config :

<system.webServer>
  ...
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
  ...
</system.webServer>

Para X-AspNet-Version y X-AspNetMvc-Version Scott Mitchell propose une meilleure solution que de les supprimer à chaque réponse : il suffit de ne pas les générer du tout.

Utilisez enableVersionHeader pour l'invalidation X-AspNet-Version dans le web.config

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

Utilisez MvcHandler.DisableMvcResponseHeader dans l'événement Application_Start de .Net pour désactiver X-AspNetMvc-Version

MvcHandler.DisableMvcResponseHeader = true;

Et enfin, supprimez dans la configuration d'IIS le X-Powered-By en-tête personnalisé dans le web.config.

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

Attention, si vous disposez d'un système ARR (Application Request Routing), il ajoutera également son propre système de gestion de la qualité. X-Powered-By qui ne sera pas supprimé par les paramètres des en-têtes personnalisés. Celui-ci doit être supprimé par le gestionnaire IIS, configuration de l'éditeur sur la racine IIS (pas sur un site) : allez à system.webServer/proxy et définir arrResponseHeader a false . Après une IISReset il est pris en compte.
(J'ai trouvé celui-ci ici (sauf que cet article traite de l'ancienne façon de configurer IIS 6.0).

N'oubliez pas que la solution par code d'application ne s'applique pas par défaut aux en-têtes générés sur du contenu statique (vous pouvez activer la fonction runAllManagedModulesForAllRequests pour changer cela, mais cela entraîne l'exécution de toutes les demandes par le pipeline .Net). Ce n'est pas un problème pour X-AspNetMvc-Version puisqu'il n'est pas ajouté sur le contenu statique (du moins si les requêtes statiques ne sont pas exécutées dans le pipeline .Net).

Remarque : lorsque l'objectif est de masquer la technologie utilisée, vous devez également changer les noms de cookies standard .Net ( .ASPXAUTH si l'authentification des formulaires est activée (utiliser name l'attribut forms dans le web.config), ASP.NET_SessionId (utiliser <sessionState cookieName="yourName" /> dans web.config sous system.web tag), __RequestVerificationToken (changez-le par code avec AntiForgeryConfig.CookieName mais ne s'applique malheureusement pas à l'entrée cachée que ce système génère dans le html)).

Answer 4

Avec le module de réécriture d'URL version 2.0 pour IIS (UrlRewrite) activé, dans la section de configuration <configuration> ➡ <system.webServer> ➡ <rewrite> ajouter la règle de sortie :

<outboundRules>
  <rule name="Remove RESPONSE_Server" >
    <match serverVariable="RESPONSE_Server" pattern=".+" />
    <action type="Rewrite" value="" />
  </rule>
</outboundRules>

Answer 5

Ce site web.config permet de supprimer tous les en-têtes inutiles de la réponse ASP.NET (au moins à partir de IIS 10) :

<system.web>
    <!-- Removes version headers from response -->
    <httpRuntime enableVersionHeader="false" />
</system.web>

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <!--Removes X-Powered-By header from response -->
            <clear />
        </customHeaders>
    </httpProtocol>

    <security>
        <!--Removes Server header from response-->
        <requestFiltering removeServerHeader ="true" />
    </security>
</system.webServer>

Veuillez noter que cette méthode masque tous les en-têtes de l'"application", comme le font toutes les autres approches. Si vous atteignez, par exemple, une page par défaut ou une page d'erreur générée par IIS lui-même ou ASP.NET en dehors de votre application, ces règles ne s'appliqueront pas. Idéalement, elles devraient donc se situer au niveau de la racine dans IIS, ce qui peut encore laisser des réponses d'erreur à IIS lui-même.

P.S. Il y a un bogue dans IIS 10 qui fait qu'il affiche parfois l'en-tête du serveur même avec une configuration correcte. Cela devrait être corrigé maintenant, mais IIS/Windows doit être mis à jour.