In che modo il metodo OPTIONS HTTP determina i metodi consentiti in IIS 8.5?


8

Sto cercando di rimuovere il TRACEmetodo dal mio sito Web in IIS 8.5 (Windows Server 2012 R2 Datacenter). Ho implementato questo utilizzando il filtro richieste come di seguito:

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

Questo impedisce che TRACEle richieste, ma se mando una OPTIONSrichiesta, elenca ancora fuori TRACEnel Allowe Publicintestazioni. Ho reimpostare IIS, ma non riesco a TRACEuscire di OPTIONS. Non voglio negare OPTIONS.

Ciò è problematico perché sembra che una scansione di conformità che rispettiamo utilizzi OPTIONScome indicatore TRACEabilitato. So che questo non è corretto, ma questo è il criterio che devo soddisfare.

Esiste un modo per ottenere OPZIONI per segnalare correttamente i metodi disponibili?

Risposte:


6

Domanda interessante. Tutti i metodi da rimuovere response headersda IIS non sembrano funzionare per le intestazioni Allowe Public, una OPTIONSrichiesta restituisce sempre:

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

indipendentemente da ciò che il server effettivamente consente.

Tutte le richieste in IIS sono gestite da moduli, le OPTIONSrichieste sono gestite da ciò ProtocolSupportModuleche non è essenziale e in quanto sembra piuttosto stupido.

Se rimuoviamo quel modulo, il server non risponde più alla richiesta di Opzioni, che vuoi ancora supportare, quindi dobbiamo usare un altro modulo per rispondere a queste.

Aperto:

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

e cerca un OPTIONSVerbHandlercommento su quella riga e mentre ci sei sopra anche quella sopra ( TRACEVerbHandler). Ora aggiungi un nuovo nodo:

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

l'intero blocco dovrebbe apparire così:

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

Ora staticFileModule elaborerà le OPTIONSrichieste ma non restituirà alcun contenuto.

Se ora fai una OPTIONSrichiesta al server, non otterrai AllowPublicun'intestazione, puoi aggiungerli facilmente in web.config

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

ora le tue OPTIONSrichieste funzionano come richiesto, ma quelle intestazioni extra vengono inviate anche con qualsiasi GETo POSTche ritengo sia ancora valido http.

Se si desidera utilizzare solo queste intestazioni per le OPTIONSrichieste, è possibile scrivere un semplice modulo http che imposta queste intestazioni e utilizzarlo al posto del StaticFileModule che ho usato sopra.


grazie per la risposta, mi ero chiesto se fosse necessario sostituire il gestore OPTIONS, la tua risposta mi ha fornito un percorso per gestirlo.
alergy,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.