Comment la méthode HTTP OPTIONS détermine-t-elle les méthodes autorisées dans IIS 8.5?

8

Je cherche à supprimer la TRACEméthode de mon site Web dans IIS 8.5 (Windows Server 2012 R2 Datacenter). J'ai mis en œuvre cela en utilisant le filtrage des demandes comme ci-dessous:

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

Cela empêche les TRACEdemandes, mais si j'envoie une OPTIONSdemande, elle apparaît toujours TRACEdans les en Allow- Publictêtes et . J'ai remis à zéro IIS, mais ne peut pas obtenir TRACEsur OPTIONS. Je ne veux pas nier OPTIONS.

Ceci est problématique car il semble qu'une analyse de conformité que nous respectons utilise OPTIONScomme indicateur TRACEactivé. Je sais que ce n'est pas correct, mais c'est le critère que je dois respecter.

Existe-t-il un moyen d'obtenir OPTIONS pour signaler correctement les méthodes disponibles?

alergie
la source

Réponses:

6

Question interessante. Toutes les méthodes à supprimer response headersd'IIS ne semblent pas fonctionner pour les en Allow- Publictêtes et , une OPTIONSdemande renvoie toujours:

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

indépendamment de ce que le serveur autorise réellement.

Toutes les demandes dans IIS sont gérées par des modules, les OPTIONSdemandes sont gérées par le ProtocolSupportModulequi n'est pas essentiel et comme cela semble assez stupide.

Si nous supprimons ce module, le serveur ne répond plus à la demande d'options, que vous souhaitez toujours prendre en charge, nous devons donc utiliser un autre module pour y répondre.

Ouvert:

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

et recherchez un OPTIONSVerbHandlercommentaire sur cette ligne et pendant que vous y êtes, celle ci-dessus ( TRACEVerbHandler) aussi. Ajoutez maintenant un nouveau nœud:

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

le bloc entier devrait ressembler à ceci:

    <!--  <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" /> 

Maintenant, le staticFileModule traitera les OPTIONSdemandes mais ne retournera aucun contenu.

Si vous faites maintenant une OPTIONSdemande au serveur, vous n'obtiendrez Allowni un en- Publictête, vous pouvez les ajouter facilement dans web.config

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

maintenant vos OPTIONSdemandes fonctionnent comme requis, mais ces en-têtes supplémentaires sont également envoyés avec n'importe quelle GETou des POSTdemandes qui, je pense, sont toujours valides http.

Si vous souhaitez uniquement utiliser ces en-têtes pour les OPTIONSdemandes, vous pouvez écrire un module http simple qui définit ces en-têtes et l'utiliser à la place du StaticFileModule que j'ai utilisé ci-dessus.

Peter Hahndorf
la source
merci pour la réponse, je m'étais demandé si le gestionnaire OPTIONS avait besoin d'être remplacé, votre réponse me donne un itinéraire pour gérer cela.
alergy