Wie ermittelt die HTTP OPTIONS-Methode die zulässigen Methoden in IIS 8.5?

Ich möchte die TRACEMethode von meiner Website in IIS 8.5 (Windows Server 2012 R2 Datacenter) entfernen . Ich habe dies mithilfe der Anforderungsfilterung wie folgt implementiert:

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

Dies verhindert TRACEAnfragen, aber wenn ich eine OPTIONSAnfrage sende , wird sie immer noch TRACEin den Headern Allowund Publicaufgelistet. Ich habe IIS zurückgesetzt, komme aber nicht TRACEraus OPTIONS. Ich will nicht leugnen OPTIONS.

Dies ist problematisch, da anscheinend ein Compliance-Scan, an den wir uns halten OPTIONS, TRACEals aktivierter Indikator verwendet wird. Ich weiß, dass dies nicht korrekt ist, aber das sind die Kriterien, die ich erfüllen muss.

Gibt es eine Möglichkeit, OPTIONEN dazu zu bringen, die verfügbaren Methoden korrekt zu melden?

Interessante Frage. Alle Methoden zum Entfernen response headersaus IIS scheinen für die Header Allowund nicht zu funktionieren. PublicEine OPTIONSAnforderung gibt immer Folgendes zurück:

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

unabhängig davon, was der Server tatsächlich zulässt.

Alle Anforderungen in IIS werden von Modulen verarbeitet, die OPTIONSAnforderungen werden von den Modulen verarbeitet, ProtocolSupportModulewas nicht unbedingt erforderlich ist und wie es ziemlich dumm erscheint.

Wenn wir dieses Modul entfernen, antwortet der Server nicht mehr auf die Optionsanforderung, die Sie weiterhin unterstützen möchten. Daher müssen wir ein anderes Modul verwenden, um diese zu beantworten.

Öffnen:

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

und suche nach OPTIONSVerbHandlerKommentaren in dieser Zeile und während du dabei bist, auch in der obigen ( TRACEVerbHandler). Fügen Sie nun einen neuen Knoten hinzu:

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

Der ganze Block sollte so aussehen:

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

Jetzt verarbeitet das staticFileModule die OPTIONSAnforderungen, gibt jedoch keinen Inhalt zurück.

Wenn Sie jetzt eine OPTIONSAnfrage an den Server stellen, erhalten Sie Allowweder einen noch einen PublicHeader. Sie können diese einfach in web.config hinzufügen

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

jetzt Ihre OPTIONSAnfragen nach Bedarf arbeiten, aber diese zusätzlichen Header werden auch mit jedem gesendeten GEToder POSTAnfragen , die ich denke immer noch gültig http ist.

Wenn Sie diese Header nur für OPTIONSAnforderungen verwenden möchten, können Sie ein einfaches http-Modul schreiben, das diese Header festlegt, und es anstelle des oben verwendeten StaticFileModule verwenden.