Como o método HTTP OPTIONS determina os métodos permitidos no IIS 8.5?

Question

Estou tentando remover o método TRACE do meu site no IIS 8.5 (Windows Server 2012 R2 Datacenter). Eu implementei isso usando a filtragem de solicitações, conforme abaixo:

<system.webServer>
  <security>
    <requestFiltering>
      <verbs allowUnlisted="true">
        <add verb="TRACE" allowed="false" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

Isso evita TRACE solicitações, mas se eu enviar uma solicitação OPTIONS , ela ainda listará TRACE nos cabeçalhos Allow e Public . Eu restaurei o IIS, mas não consigo obter TRACE de OPTIONS . Não quero negar OPTIONS .

Isso é problemático porque parece que uma varredura de conformidade que seguimos usa OPTIONS como seu indicador de que TRACE está habilitado. Eu sei que isso não está correto, mas esse é o critério que eu tenho que cumprir.

Existe alguma maneira de obter as OPÇÕES para relatar os métodos disponíveis corretamente?

    

Answer 1

Pergunta interessante. Todos os métodos para remover response headers do IIS parecem não funcionar para os cabeçalhos Allow e Public , uma solicitação OPTIONS sempre retorna:

Allow:  OPTIONS, TRACE, GET, HEAD, POST
Public: OPTIONS, TRACE, GET, HEAD, POST

, independentemente do que o servidor realmente permita.

Todas as solicitações no IIS são tratadas por módulos, as solicitações OPTIONS são manipuladas pelo ProtocolSupportModule , o que não é essencial e parece bastante burro.

Se removermos esse módulo, o servidor não responderá mais à solicitação de Opções, o que você ainda deseja suportar, então temos que usar outro módulo para respondê-lo.

Aberto:

%SystemRoot%\System32\inetsrv\config\applicationHost.config

e pesquise por OPTIONSVerbHandler comente essa linha e, enquanto estiver, a mesma acima ( TRACEVerbHandler ) também. Agora adicione um novo nó:

<add name="MyOPTIONSVerbHandler" path="*" verb="OPTIONS" modules="StaticFileModule" requireAccess="None" />

o bloco inteiro deve ficar assim:

    <!--  <add name="TRACEVerbHandler" path="*" verb="TRACE" modules="ProtocolSupportModule" requireAccess="None" /> 
          <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" modules="ProtocolSupportModule" requireAccess="None" /> -->
          <add name="MyOPTIONSVerbHandler" path="*" verb="OPTIONS" modules="StaticFileModule" requireAccess="None" /> 

Agora, o staticFileModule processará as solicitações OPTIONS , mas não retornará nenhum conteúdo.

Se você agora fizer uma solicitação OPTIONS para o servidor, você não obterá um Allow nem um Public , você pode adicioná-los facilmente em web.config

<system.webServer>
 <httpProtocol>
      <customHeaders>
          <add name="Allow"  value="GET,POST,HEAD" />  
          <add name="Public" value="GET,POST,HEAD" />
      </customHeaders>
  </httpProtocol>        
</system.webServer>

agora, as solicitações de OPTIONS funcionam conforme o necessário, mas esses cabeçalhos extras também são enviados com qualquer solicitação GET ou POST , o que ainda acho válido.

Se você quiser usar apenas esses cabeçalhos para OPTIONS solicitações, poderá escrever um módulo http simples que define esses cabeçalhos e usá-los em vez do StaticFileModule que eu usei acima.