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

107

Existe-t-il un moyen de supprimer l'en-tête de réponse "Server" d'IIS7? Certains articles montrent qu'en utilisant HttpModules, nous pouvons réaliser la même chose. Cela sera utile si nous n'avons pas le droit d'administrateur sur le serveur. Je ne veux pas non plus écrire de filtre ISAPI.

J'ai des droits d'administrateur sur mon serveur. Donc je ne veux pas faire les choses ci-dessus. Alors, aidez-moi à faire de même.

user247702
la source
Voir: stackoverflow.com/questions/22401219/…
Mohsen Tavoosi محسن طاوسی

Réponses:

111

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");
}
bkaid
la source
11
Je ne sais pas pourquoi la réponse du module http est supérieure à celle-ci, celle-ci est beaucoup plus facile
jjxtra
2
Vous pourriez trouver que vous obtenez un NullReferenceExceptionà Cassini si vous comptez sur HttpContext.Current. Cet article de blog montre comment le faire tout en évitant de casser le support Cassini, si cela est important pour vous.
Owen Blacker
49
@PsychoDad cela fonctionne uniquement pour les requêtes ASP.NET, pas pour les fichiers statiques comme .css et .js
Max Toro
1
Pour vous débarrasser de l'en-tête MVC, vous pouvez faire ceci MvcHandler.DisableMvcResponseHeader = true;
ProVega
7
Ce n'est pas une bonne idée d'utiliser le PreSendRequestHeadersdans une classe qui implémente IHttpModuleou Global.asax. J'ai été témoin de l'événement gelant l'application sur le serveur sous une charge de stress. L' BeginRequestévénement devrait fonctionner pour apporter des modifications d'en-tête de réponse. Voir hanselman.com/blog/ChecklistWhatNOTToDoInASPNET.aspx .
Dmitry S.
77

Dans IIS7, vous devez utiliser un module HTTP. Créez ce qui suit en tant que bibliothèque de classes 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 vous le configurez dans IIS (si vous configurez dans IIS, l'assembly doit être dans le GAC).

<configuration>
  <system.webServer>
    <modules>
      <add name="CustomHeaderModule"
       type="StrongNamespace.HttpModules.CustomHeaderModule" />
    </modules>
  </system.webServer>
</configuration>
lukiffer
la source
Excellent, je peux également modifier cela pour supprimer l'en-tête ETag de ma batterie de serveurs.
devstuff
Cela provoque une erreur d'exécution dans le serveur casini ... / ASP.NET Dev
UpTheCreek
2
@UpTheCreek Le serveur de développement ASP.Net (Cassini) n'aimera pas ce code; ce blog a une solution à ce problème , bien que - vous devez vérifier que la HttpApplication, la HttpRequest, la HttpContext, et HttpResponsene sont pas null, ainsi que la vérification qui HttpRequest.IsLocalest false.
Owen Blacker
2
Comme la modification de l'en-tête dans PreSendRequestHeaderspeut causer des problèmes avec HttpCacheModule , vous devriez utiliser quelque chose comme à la PostReleaseRequestStateplace.
Eirik H
5
Le module n'est pas appelé lorsque IIS envoie un en-tête 304 Not Modified pour les fichiers statiques (css / less / images / etc) car cela n'atteint pas le pipeline ASP.NET, donc dans cette situation Serveur: Microsoft IIS / 7.5 est toujours rendu
Jano
42

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

<outboundRules>
  <rule name="Remove RESPONSE_Server" >
    <match serverVariable="RESPONSE_Server" pattern=".+" />
    <action type="Rewrite" value="" />
  </rule>
</outboundRules>
JeffZhnn
la source
11
Notez que cela vide uniquement l'en-tête du serveur, cela ne le supprime pas.
Nick Evans
Désolé pour l'ignorance mais à quelle partie dois-je ajouter cela?! J'ai essayé de l'ajouter dans <system.webServer>
Vignesh Subramanian
1
Merci! Fonctionne dans IIS 8.5, c'est tellement simple. Je n'ai pas d'éditeur de texte mais vous pouvez facilement utiliser l'interface graphique. Le nom doit être RESPONSE_Server, pas seulement Server (c'est là que j'ai échoué au début).
Louis Matthijssen
c'est assez bien si vous avez une application non-ASP.Net pour cela, vous ne pouvez pas supprimer l'en-tête du serveur avec les codes mentionnés
mhesabi
4
@vignesh voici quelques sous-nœuds de configuration UrlRewrite. Vous devez les mettre sous un rewritenœud dans system.webServer. Attention, cela plantera votre site si UrlRewrite n'est pas installé sur le serveur. Et vous feriez mieux d'utiliser d'abord la console de configuration IIS pour vérifier comment elle écrit ces nœuds de configuration.
Frédéric
36

Scott Mitchell propose dans un article de blog des solutions pour supprimer les en-têtes inutiles .

Comme déjà dit ici dans d'autres réponses, pour l'en- Servertête, il existe la solution de module http , ou une solution web.config pour IIS 10+ , ou vous pouvez utiliser URLRewrite à la place pour le supprimer .

La solution la plus pratique pour une configuration à jour (IIS 10 +) consiste à utiliser removeServerHeaderdans le web.config:

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

Pour X-AspNet-Versionet X-AspNetMvc-Version, il offre un meilleur moyen que de les supprimer à chaque réponse: simplement ne pas les générer du tout.

Utiliser enableVersionHeaderpour désactiver X-AspNet-Version, dans web.config

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

Utilisation MvcHandler.DisableMvcResponseHeaderdans l'événement .Net Application_Start pour la désactivationX-AspNetMvc-Version

MvcHandler.DisableMvcResponseHeader = true;

Et enfin, supprimez dans la configuration IIS l'en- X-Powered-Bytête personnalisé dans web.config.

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

Attention, si vous avez ARR (Application Request Routing), il ajoutera également le sien X-Powered-By, qui ne sera pas supprimé par les paramètres d'en-têtes personnalisés. Celui-ci doit être supprimé via le gestionnaire IIS, configuration de l'éditeur sur la racine IIS (pas sur un site): accédez au system.webServer/proxynœud et définissez-le arrResponseHeadersur false. Après un IISReset, il est pris en compte.
(J'ai trouvé celui-ci ici , sauf que cet article concerne l'ancienne manière de configurer les choses par IIS 6.0.)

N'oubliez pas que la solution par code d'application ne s'applique pas par défaut à l'en-tête généré sur le contenu statique (vous pouvez activer le runAllManagedModulesForAllRequestspour modifier cela, mais cela entraîne toutes les requêtes à exécuter le pipeline .Net). Ce n'est pas un problème pourX-AspNetMvc-Version car 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 ( .ASPXAUTHsi l'authentification des formulaires est activée (utiliser l' nameattribut sur la formsbalise dans web.config), ASP.NET_SessionId(utiliser <sessionState cookieName="yourName" />dans web.config sous la system.webbalise), __RequestVerificationToken(le modifier 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)).

Frédéric
la source
18

En fait, les modules codés et les exemples Global.asax présentés ci-dessus ne fonctionnent que pour les requêtes valides.

Par exemple, ajoutez <à la fin de votre URL et vous obtiendrez une page "Demande incorrecte" qui expose toujours l'en-tête du serveur. Beaucoup de développeurs oublient cela.

Les paramètres de registre affichés ne fonctionnent pas non plus. URLScan est le SEUL moyen de supprimer l'en-tête «serveur» (au moins dans IIS 7.5).

Dan Ware
la source
Cela fonctionne pour moi avec le module codé (ajouté dans web.config) même sur une mauvaise requête;) Dans global.asax cela ne fonctionne pas vraiment (par exemple les fichiers statiques, etc.)
kapsiR
J'espère que la validation de la demande est toujours activée.
Dan Ware
1
Quelqu'un at-il une alternative à urlscan pour IIS 8+?
herostwist
Il existe une solution de travail au moins dans IIS10 +: stackoverflow.com/a/53222967/1671558
Ilya Chernomordik
16

Ou ajoutez dans web.config:

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <remove name="X-AspNet-Version" />
            <remove name="X-AspNetMvc-Version" />
            <remove name="X-Powered-By" />
            <!-- <remove name="Server" />  this one doesn't work -->
        </customHeaders>
    </httpProtocol>
</system.webServer>
Anders
la source
3
Cette méthode ne supprime pas l'en-tête «Server». Les autres sont supprimés.
Pure.Krome
Vous pouvez vous débarrasser du X-Powered-By dans la configuration des en-têtes de réponse au niveau du serveur.
Snowburnt
1
Je ne sais pas s'il existe des cas où cette façon supprime X-AspNet-Versionet en- X-AspNetMvc-Versiontête. Ce que je sais, c'est que cette méthode ne fonctionne pas toujours (si cela fonctionne un jour). Voir la réponse @Frederic pour un moyen plus fiable de les supprimer.
TheBlueSky
Il existe maintenant un moyen dans IIS10 + de supprimer l'en-tête du serveur: stackoverflow.com/a/53222946/1671558
Ilya Chernomordik
14

Cette web.configconfiguration fonctionne pour supprimer tous les en-têtes inutiles de la réponse ASP.NET (au moins à partir d'IIS 10):

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

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

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

Veuillez noter que cela masque tous les en-têtes de "l'application", comme toutes les autres approches. Si, par exemple, vous atteignez 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. Donc, idéalement, ils devraient être au niveau racine dans IIS et ce seuil peut laisser des réponses d'erreur à IIS lui-même.

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

Ilya Chernomordik
la source
12

En plus de la réponse de réécriture d'URL , voici le XML complet pourweb.config

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

Réécriture d'URL

Vaibhav Garg
la source
Est-ce que cela supprime toutes les versions IIS et ASP du hacker
aggie
1
Le correctif ci-dessus fonctionne correctement pour les pages Web, mais pour les images / icônes, si une erreur de serveur interne 500 s'est produite, il affiche le serveur: Microsoft-IIS / 7.5 au lieu de la valeur.Pouvez-vous s'il vous plaît m'aider à ce sujet
ravithejag
11

Pour supprimer l'en- Server:tête, allez dans Global.asax, recherchez / créez l' Application_PreSendRequestHeadersévénement et ajoutez une ligne comme suit (grâce à BK et à ce blog, cela n'échouera pas non plus sur le développement Cassini / local):

protected void Application_PreSendRequestHeaders(object sender, EventArgs e)
{
    // Remove the "Server" HTTP Header from response
    HttpApplication app = sender as HttpApplication;
    if (null != app && null != app.Request && !app.Request.IsLocal &&
        null != app.Context && null != app.Context.Response)
    {
        NameValueCollection headers = app.Context.Response.Headers;
        if (null != headers)
        {
            headers.Remove("Server");
        }
    }
}

Si vous souhaitez une solution complète pour supprimer tous les en-têtes associés sur Azure / IIS7 et fonctionne également avec Cassini, consultez ce lien , qui montre la meilleure façon de désactiver ces en-têtes sans utiliser HttpModules ou URLScan.

Nick Evans
la source
9

Si vous souhaitez simplement supprimer l'en-tête, vous pouvez utiliser une version abrégée de la réponse de lukiffer:

using System.Web;

namespace Site
{
    public sealed class HideServerHeaderModule : IHttpModule
    {
        public void Dispose() { }

        public void Init(HttpApplication context)
        {
            context.PreSendRequestHeaders +=
            (sender, e) => HttpContext.Current.Response.Headers.Remove("Server");
        }
    }
}

Et puis dans Web.config:

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="CustomHeaderModule" type="Site.HideServerHeaderModule" />
  </modules>
</system.webServer>
Drew Noakes
la source
1
Ceci est le plus approprié car les ressources comme css / js n'auront pas l'en-tête Serveur, il portera de serveur à serveur sans configuration et l'en-tête de réponse Serveur ne sera pas simplement vide, il ne sera pas envoyé.
Adam Caviness
J'ai vu des commentaires selon lesquels runAllManagedModulesForAllRequests = "true" ralentira votre application et n'est pas recommandé. Au lieu de cela, on pourrait utiliser le module urlrewrite outboundRules pour effacer la valeur du serveur également pour les fichiers statiques. britishdeveloper.co.uk/2010/06/…
Juri
5

Essayez de définir l' HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeaderentrée de registre sur un REG_DWORDsur 1.

Richard Deeming
la source
Ran dans une situation étrange avec notre batterie de serveurs où ce paramètre de registre semble être le seul changement qui fonctionne sur tous les systèmes d'exploitation (W2K8, W2K3) que nous utilisons, pour IIS6 et IIS7.
jerhewet
2
Frustrant, cela ne fait aucune différence pour moi, même après le redémarrage de la machine virtuelle. Nous exécutons IIS 7.5 sur Windows Server 2008 R2 Standard, «Version 6.1 (Build 7601: Service Pack 1)». De même, mon OnPreSendRequestHeadersgestionnaire d'événements (voir ci-dessus) ne se déclenche jamais, pour une raison quelconque.
Owen Blacker
3
Malheureusement, la clé de registre ne semble pas fonctionner sur IIS 7.5
Andrew Csontos
4

UrlScan peut également supprimer l'en-tête du serveur en utilisant AlternateServerName=under [options].

Eddiegroves
la source
2

Suite à la réponse d'eddiegroves , en fonction de la version d'URLScan, vous pouvez plutôt préférer RemoveServerHeader=1sous [options].

Je ne sais pas dans quelle version d'URLScan cette option a été ajoutée, mais elle était disponible dans la version 2.5 et ultérieure.

techticien
la source
2

J'ai trouvé un article qui explique pourquoi nous devons à la fois modifier le registre et utiliser un outil tel que UrlScan pour le configurer correctement dans IIS. Je l'ai suivi sur nos serveurs et cela fonctionne: http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx . Si vous utilisez uniquement UrlScan mais que vous n'effectuez pas la modification du registre, pendant que vous arrêtez World Wide Publishing Service, votre serveur renvoie la réponse http du serveur à partir du fichier HTTP.sys. En outre, voici les pièges courants de l'utilisation de l'outil UrlScan: http://msdn.microsoft.com/en-us/library/ff648552.aspx#ht_urlscan_008

Pawel
la source
2
Veuillez publier votre code sur Stack Overflow. Les liens peuvent changer et se rompre, il est donc beaucoup plus utile de publier du code
Philosophe maladroit
2

Dans IIS 10, nous utilisons une solution similaire à l'approche de Drew, à savoir:

using System;
using System.Web;

namespace Common.Web.Modules.Http
{
    /// <summary>
    /// Sets custom headers in all requests (e.g. "Server" header) or simply remove some.
    /// </summary>
    public class CustomHeaderModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.PreSendRequestHeaders += OnPreSendRequestHeaders;
        }

        public void Dispose() { }

        /// <summary>
        /// Event handler that implements the desired behavior for the PreSendRequestHeaders event,
        /// that occurs just before ASP.NET sends HTTP headers to the client.
        /// 
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        void OnPreSendRequestHeaders(object sender, EventArgs e)
        {
            //HttpContext.Current.Response.Headers.Remove("Server");
            HttpContext.Current.Response.Headers.Set("Server", "MyServer");
        }
    }
}

Et évidemment, ajoutez une référence à cette dll dans votre (vos) projet (s) ainsi que le module dans la ou les config (s) que vous voulez:

<system.webServer>
    <modules>
      <!--Use http module to remove/customize IIS "Server" header-->
      <add name="CustomHeaderModule" type="Common.Web.Modules.Http.CustomHeaderModule" />
    </modules>
</system.webServer>

REMARQUE IMPORTANTE 1: Cette solution nécessite un pool d'applications défini comme intégré;

REMARQUE IMPORTANTE2: Toutes les réponses de l'application Web seront affectées par cela (css et js inclus);

Xautau
la source
1

J'avais recherché ceci et la méthode URLRewrite fonctionne bien. Je n'arrive pas à trouver le changement scripté n'importe où. J'ai écrit ceci compatible avec PowerShell v2 et supérieur et l'ai testé sur IIS 7.5.

# Add Allowed Server Variable
    Add-WebConfiguration /system.webServer/rewrite/allowedServerVariables -atIndex 0 -value @{name="RESPONSE_SERVER"}
# Rule Name
    $ruleName = "Remove Server Response Header"
# Add outbound IIS Rewrite Rule
    Add-WebConfigurationProperty -pspath "iis:\" -filter "system.webServer/rewrite/outboundrules" -name "." -value @{name=$ruleName; stopProcessing='False'}
#Set Properties of newly created outbound rule 
    Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST"  -filter "system.webServer/rewrite/outboundRules/rule[@name='$ruleName']/match" -name "serverVariable" -value "RESPONSE_SERVER"
    Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST"  -filter "system.webServer/rewrite/outboundRules/rule[@name='$ruleName']/match" -name "pattern" -value ".*"
    Set-WebConfigurationProperty -pspath "MACHINE/WEBROOT/APPHOST"  -filter "system.webServer/rewrite/outboundRules/rule[@name='$ruleName']/action" -name "type" -value "Rewrite"
Bill M
la source
1

Vous pouvez ajouter le code ci-dessous dans le fichier Global.asax.cs

    protected void Application_PreSendRequestHeaders()
    {
        Response.Headers.Remove("Server");
    }
Dharmendra Kumar Sharma
la source
1

La solution proposée ci-dessus en combinaison a fonctionné pour moi avec les changements suivants. Ici, je poste mon scénario et ma solution.

Pour moi, je voulais supprimer les en-têtes suivants:

  • Serveur
  • X-Powered-By
  • Version X-AspNet
  • Version X-AspNetMvc

J'ai ajouté ces derniers à mon global.asax:

<%@ Application Language="C#" %>
<script runat="server">
    protected void Application_PreSendRequestHeaders()
    {
        Response.Headers.Remove("Server");
        Response.Headers.Remove("X-Powered-By");
        Response.Headers.Remove("X-AspNet-Version");
        Response.Headers.Remove("X-AspNetMvc-Version");
    }
</script>

L'événement ci-dessus ne se déclenchait pas, donc pour cela, j'ai ajouté le suivi à web.config, puis cela a fonctionné.

<modules runAllManagedModulesForAllRequests="true" />

et pour supprimer l'en-tête de version, j'ai également ajouté ce qui suit à web.config:

<httpRuntime enableVersionHeader="false" />

Changements dans web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true" />
    </system.webServer>
    <system.web>
        <httpRuntime enableVersionHeader="false" />
    </system.web>
</configuration>

J'espère que ça aide!

Zaki Mohammed
la source
0

J'ai essayé toutes les choses ici et sur plusieurs autres threads de débordement de pile similaires.

J'ai raccroché un peu parce que j'ai oublié de vider le cache de mon navigateur après avoir apporté des modifications de configuration. Si vous ne le faites pas et que le fichier est dans votre cache local, il vous le servira avec les en-têtes d'origine (duh).

Je l'ai fait fonctionner principalement en supprimant les runAllManagedModulesForAllRequests:

<modules runAllManagedModulesForAllRequests="true">

Cela a supprimé les en-têtes superflus de la plupart des fichiers statiques, mais j'obtenais toujours l'en-tête "Server" sur certains fichiers statiques de mon projet WebAPI dans swagger.

J'ai finalement trouvé et appliqué cette solution et maintenant tous les en-têtes indésirables ont disparu:

https://www.dionach.com/blog/easily-remove-unwanted-http-headers-in-iis-70-to-85

qui traite de son code qui se trouve ici:

https://github.com/Dionach/StripHeaders/releases/tag/v1.0.5

Ceci est un module de code natif. Il est capable de supprimer l'en-tête du serveur, pas seulement de supprimer la valeur. Par défaut, il supprime:

  • Serveur
  • X-Powered-By
  • Version X-Aspnet
  • Serveur: Microsoft-HTTPAPI / 2.0 - qui serait renvoyé si "la demande ne parvient pas à être transmise à IIS"
TechSavvySam
la source
-1

IIS 7.5 et éventuellement les versions plus récentes ont le texte d'en-tête stocké dans iiscore.dll

À l'aide d'un éditeur hexadécimal, recherchez la chaîne et le mot «Serveur» 53 65 72 76 65 72après et remplacez-les par des octets nuls. Dans IIS 7.5, cela ressemble à ceci:

4D 69 63 72 6F 73 6F 66 74 2D 49 49 53 2F 37 2E 35 00 00 00 53 65 72 76 65 72 

Contrairement à d'autres méthodes, cela n'entraîne pas de pénalité de performances. L'en-tête est également supprimé de toutes les demandes, même des erreurs internes.

3dcdr
la source