Remover / ocultar / desativar cabeçalhos de resposta HTTP excessivos no Azure / IIS7 sem UrlScan


86

Preciso remover cabeçalhos excessivos (principalmente para passar no teste de penetração). Passei um tempo procurando soluções que envolvem a execução do UrlScan, mas elas são complicadas, pois o UrlScan precisa ser instalado sempre que uma instância do Azure é iniciada .

Deve haver uma boa solução para o Azure que não envolva a implantação de instaladores de startup.cmd.

Eu entendo que os cabeçalhos de resposta são adicionados em lugares diferentes :

  • Servidor : adicionado pelo IIS.
  • Versão X-AspNet : adicionado por System.Web.dll no momento de Flush na classe HttpResponse
  • X-AspNetMvc-Version : adicionado por MvcHandler em System.Web.dll.
  • X-Powered-By : adicionado por IIS

Existe alguma maneira de configurar (via web.config etc.?) O IIS7 para remover / ocultar / desabilitar os cabeçalhos de resposta HTTP para evitar o aviso "Cabeçalhos excessivos" em asafaweb.com , sem criar um módulo IIS ou implantar instaladores que precisam ser executado sempre que uma instância do Azure é iniciada?

Respostas:


139

As seguintes alterações permitem que você remova esses cabeçalhos de resposta HTTP no Azure sem escrever um HttpModule personalizado.

A maioria das informações na rede está desatualizada e envolve o UrlScan (que já foi integrado ao IIS7, mas com a RemoveServerHeader=1opção removida). Abaixo está a solução mais legal que encontrei (graças a este blog , esta resposta e este blog combinados).

Para remover o Server , acesse Global.asax, encontre / crie o Application_PreSendRequestHeadersevento e adicione o seguinte (graças a BK e a este blog isso também não falhará no Cassini / dev local):

Editado em abril de 2014: você pode usar os eventos PreSendRequestHeaders e PreSendRequestContext com módulos IIS nativos, mas não os use com módulos gerenciados que implementam IHttpModule. Definir essas propriedades pode causar problemas com solicitações assíncronas . A versão correta é usar o evento 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");
        }
    }

Para remover o X-AspNet-Version , no web.config encontre / crie <system.web>e adicione:

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

    ...

Para remover X-AspNetMvc-Version , vá para Global.asax, encontre / crie o Application_Startevento e adicione uma linha da seguinte forma:

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

Para remover o X-Powered-By , no web.config, localize / crie <system.webServer>e adicione:

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

    ...

De acordo com a sugestão do VS, não há necessidade de anular a verificação de Solicitação, Resposta ou Resposta.Headers
Chris Haines

1
Quando usado no IIS, não no Azure, esteja ciente de que o pool de aplicativos deve estar no modo integrado. E .IsLocal deve ser removido durante a depuração local.
IvanH de

5
Não há necessidade de "condições Yoda" em C # - não permite atribuição em uma condição, en.wikipedia.org/wiki/Yoda_Conditions
tvanfosson

1
Obrigado pela resposta detalhada, no entanto, eu tentei e segui as etapas, mas cada vez que examino o site usando asafweb, ainda menciona um problema sobre o cabeçalho excessivo (X-AspNet-Version). Eu até usei o URLRewrite para remover este cabeçalho. Existem outras possibilidades de removê-lo?
Raymond A,

4
Ainda existe o problema de solicitar um arquivo inexistente, por exemplo, " seusite / foo.jpg ". Como essa solicitação não é processada pelo MVC, o cabeçalho de resposta "Servidor: IIS xy" ainda estará lá. Uma solução que funciona para sites do Azure (e aparentemente SOMENTE para sites do azul) é adicioná-lo em <system.webServer>: <security xdt: Transform = "Insert"> <requestFiltering removeServerHeader = "true" /> </ security >
adrian h.

12

O MSDN publicou este artigo sobre como ocultar cabeçalhos em sites do Azure. Agora você pode ocultar o servidor de web.config adicionando uma entrada a system.webServer

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

VS irá olhar para o acima como inválido. O link acima tem código como fotos, difíceis de encontrar. A versão MVC ainda está oculta no início do aplicativo como acima, o mesmo para a versão x-powered-by e .Net.


3
Isso é exatamente o que eu estava procurando. Obrigado.
Martin Costello

3
Isso pode funcionar para o Azure, mas não em qualquer outro lugar. Os comentários naquele artigo confirmam isso, assim como meus próprios testes. A resposta por @ giveme5minutes é a maneira que funciona.
CrazyPyro

Seria bom saber o que foi implementado para fazer esta função: | Principalmente porque o URL SCAN já o implementava de maneira imediata.
felickz

6

Também existe um pacote no NuGet que ajuda você a conseguir isso por meio de algumas linhas de configuração e nenhuma alteração no código: NWebsec. Os documentos sobre como remover cabeçalhos de versão podem ser encontrados aqui: https://github.com/NWebsec/NWebsec/wiki/Suppressing-version-headers

É demonstrado aqui: http://www.nwebsec.com/HttpHeaders/VersionHeaders (no Azure)

Isenção de responsabilidade: sou o desenvolvedor do projeto.


"O NWebsec ajuda a suprimir quase todos esses cabeçalhos de versão, ou seja, todos, exceto o cabeçalho Server: Microsoft-IIS / 8.0." :( github.com/NWebsec/NWebsec/wiki/Suppressing-version-headers
felickz

Ele mudou do codeplex para o GitHub (atualize o link github.com/NWebsec/NWebsec/wiki )
Nordes

6

A resposta de Nick Evans é perfeita, mas ...

Se você remover esses cabeçalhos por motivos de segurança , não se esqueça de alterar o ASP.NET Session coockie name! Porque é mais fácil adivinhar o idioma usado ou a versão do servidor quando você vê isto:

insira a descrição da imagem aqui

Para alterar o nome do cookie: (seja criativo)

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

Alterar o nome do cookie tem mais benefícios do que apenas a exposição da tecnologia do servidor - por exemplo, reduz o risco de coleta genérica de sessão em massa
mlhDev

4

Reunindo as respostas anteriores de @ giveme5minutes e @AKhooli, já que se relacionam aos sites do Azure, além de alguns outros itens que o scanner deseja ver, essas são as alterações que fiz para deixar o ASafaWeb feliz com um site do Azure.

Ele ainda reclama sobre o cookie de cabeçalho de afinidade do Azure não ser apenas https, mas afinidade é o tipo de cookie que você deseja que seja reproduzido de qualquer maneira, certo?

<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>
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.