Est-il possible de supprimer l'en-tête de réponse "Serveur" de IIS7? Certains articles montrent que l'utilisation de HttpModules permet d'atteindre le même objectif. Cela sera utile si nous n'avons pas le droit d'administrateur sur le serveur. Aussi, je ne veux pas é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.
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");
}
Dans IIS7, vous devez utiliser un module HTTP. Construisez les éléments suivants 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 les éléments suivants à votre configuration Web ou configurez-le dans IIS (si vous configurez dans IIS, l’ensemble doit se trouver dans le GAC).
<configuration>
<system.webServer>
<modules>
<add name="CustomHeaderModule"
type="StrongNamespace.HttpModules.CustomHeaderModule" />
</modules>
</system.webServer>
</configuration>
utiliser le IIS UrlRewrite 2.0
<outboundRules>
<rule name="Remove RESPONSE_Server" >
<match serverVariable="RESPONSE_Server" pattern=".+" />
<action type="Rewrite" value="" />
</rule>
</outboundRules>
Scott Mitchell fournit dans un blog des solutions pour supprimer les en-têtes inutiles .
Comme cela a déjà été dit dans d'autres réponses, l'en-tête Server
contient la solution du module http ou le module UrlScan. (Le module URLScan n'est plus disponible dans IIS7.5 +. Utilisez URLRewrite à la place pour le supprimer .)
Pour X-AspNet-Version
et X-AspNetMvc-Version
, il fournit un meilleur moyen que de les supprimer à chaque réponse: ne les générez tout simplement pas.
Utilisez enableVersionHeader
pour désactiver X-AspNet-Version
, dans web.config
<httpRuntime enableVersionHeader="false" />
Utilisez MvcHandler.DisableMvcResponseHeader
dans l'événement .Net Application_Start pour désactiver X-AspNetMvc-Version
MvcHandler.DisableMvcResponseHeader = true;
Enfin, supprimez dans la configuration IIS l'en-tête personnalisé X-Powered-By
. (Cela peut être fait dans web.config, configuration/system.webServer/httpProtocol/customHeaders/remove[name=X-Powered-By]
)
Attention, si vous avez ARR (Application Request Routing), il ajoutera également son propre X-Powered-By
, qui ne sera pas supprimé par les paramètres d'en-tête personnalisés. Celui-ci doit être supprimé via la configuration de l'éditeur IIS Manager, à la racine IIS (et non sur un site): accédez au noeud system.webServer/proxy
et définissez la variable arrResponseHeader
sur false
. Après une IISReset
, il est pris en compte.
(J'ai trouvé celui-ci ici , sauf que cet article concerne l'ancien IIS 6.0 façon de configurer les choses.)
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 variable runAllManagedModulesForAllRequests
pour le modifier, mais toutes les demandes sont exécutées en tant que pipeline .Net). Ce n'est pas un problème pour X-AspNetMvc-Version
puisqu'il n'est pas ajouté au contenu statique (du moins si les demandes statiques ne sont pas exécutées dans le pipeline .Net).
Remarque secondaire: lorsque l'objectif est de masquer la technologie utilisée, vous devez également modifier les noms de cookies .Net standard (.ASPXAUTH
si l'authentification de formulaire est activée (utilisez l'attribut name
sur la balise forms
dans web.config), ASP.NET_SessionId
(utilisez <sessionState cookieName="yourName" />
dans web.config sous system.web
tag), __RequestVerificationToken
(changez-le par le code avec AntiForgeryConfig.CookieName
, mais ne s'applique malheureusement pas à l'entrée cachée générée par ce système dans le code HTML)).
En réalité, les modules codés et les exemples Global.asax présentés ci-dessus ne fonctionnent que pour les demandes valides.
Par exemple, ajoutez <à la fin de votre URL et vous obtiendrez une page "Requête incorrecte" qui expose toujours l'en-tête du serveur. Beaucoup de développeurs négligent 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).
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>
Ajout à l’URL Réécriture de la réponse , voici le code XML complet pour web.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>
Pour supprimer l'en-tête Server:
, accédez à Global.asax
, recherchez/créez l'événement Application_PreSendRequestHeaders
et ajoutez une ligne comme suit (grâce à BK et ce blog cela n'échouera pas non plus sur Cassini/local dev. ):
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 fonctionnant également avec Cassini, voir ce lien , qui indique le meilleur moyen de désactiver ces en-têtes sans utiliser HttpModules ou URLScan.
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>
Essayez de définir l’entrée de registre HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader
sur REG_DWORD
de 1
.
UrlScan peut également supprimer l'en-tête du serveur à l'aide de AlternateServerName=
sous [options]
.
Cette installation de web.config
fonctionne pour supprimer tous les en-têtes inutiles de la réponse ASP.NET (au moins à partir de 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 vous par exemple atteindre 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 se trouver au niveau racine dans IIS et ce dernier peut laisser des réponses d'erreur au IIS lui-même.
P.S. Il y a un bug dans IIS 10 qui fait parfois apparaître l'en-tête du serveur même avec la configuration correcte. Il devrait être corrigé maintenant, mais IIS/Windows doit être mis à jour.
Suite à la réponse de eddiegroves , selon la version de URLScan, vous préférerez peut-être RemoveServerHeader=1
sous [options]
.
Je ne sais pas dans quelle version d'URLScan cette option a été ajoutée, mais elle est disponible dans les versions 2.5 et supérieures.
J'ai trouvé un article qui explique pourquoi nous devons modifier à la fois 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 ne modifiez pas le registre, votre serveur renvoie, pendant l'arrêt de World Wide Publishing Service, la réponse http du serveur à partir du fichier HTTP.sys. De plus, voici les pièges les plus courants liés à l'utilisation de l'outil UrlScan: http://msdn.Microsoft.com/en-us/library/ff648552.aspx#ht_urlscan_008
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 bien sûr, ajoutez une référence à cette dll dans votre (vos) projet (s) ainsi que le module dans la ou les config que vous souhaitez:
<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 IMPORTANTE1: Cette solution nécessite un pool d'applications défini comme intégré.
REMARQUE IMPORTANTE2: Toutes les réponses de l'application Web en seront affectées (css et js inclus);
J'avais fait des recherches à ce sujet et la méthode URLRewrite fonctionne bien. Je n'arrive pas à trouver le changement écrit bien. 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"
J'ai essayé toutes les choses ici et sur plusieurs autres threads similaires de débordement de pile.
Je me suis un peu accroché parce que j'avais oublié de vider le cache de mon navigateur après avoir modifié la configuration. Si vous ne le faites pas et que le fichier se trouve dans votre cache local, il vous sera restitué avec les en-têtes d'origine (duh).
Je l'ai surtout travaillé en enlevant le runAllManagedModulesForAllRequests
<modules runAllManagedModulesForAllRequests="true">
Cela supprimait les en-têtes superflus de most des fichiers statiques, mais je recevais toujours l'en-tête "Serveur" de certains fichiers statiques de mon projet WebAPI dans swagger.
J'ai finalement trouvé et appliqué cette solution et maintenant tous des en-têtes indésirables ont disparu:
https://www.dionach.com/blog/easily-remove-unwanted-http-headers-in-iis-70-to-85
qui discute de son code qui est 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 d'effacer la valeur. Par défaut, il supprime:
Vous pouvez ajouter le code ci-dessous dans le fichier Global.asax.cs
protected void Application_PreSendRequestHeaders()
{
Response.Headers.Remove("Server");
}