Rendi affidabile SERVER_NAME in IIS

Question

Rendi affidabile SERVER_NAME in IIS

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Sto cercando di correggere il più possibile la vulnerabilità di un'intestazione host dal lato server. La vulnerabilità è un attacco di intestazione dell'host HTTP. Quello che mi piacerebbe fare è solo permettere che le intestazioni host valide vengano passate attraverso le applicazioni in esecuzione. In questo modo un'intestazione host che dovrebbe essere example.com non viene trasmessa come evil.com . C'è una spiegazione decente di questa vulnerabilità qui: link .

Penso che URL Rewrite possa essere d'aiuto in questo, ma non ho molta esperienza con esso, quindi non ne sono sicuro. Qualcuno ha indurito i propri server contro questo attacco?

Il server è configurato con i collegamenti di intestazione per i domini consentiti, anche se ciò non fermerà una richiesta contenente un diverso valore di intestazione host.

Se trovo un modo per filtrare, rilevo che l'intestazione host non è corretta, quale tipo di risposta dovrebbe essere restituita?

iis vulnerability

posta Brettski 05.06.2015 - 18:17

fonte

3 risposte

Leggi altre domande sui tag iis vulnerability

Crittografia delle credenziali utente usando AES: come nascondere la chiave Quale metodo di port forwarding è più sicuro?

score 1 · Answer 1

In breve, non utilizzare i collegamenti jolly.

Associa solo nomi host applicabili a siti Web e specifica. Ad esempio, solo autorizzando www.website.com consentirà solo le richieste con quel valore di intestazione host. Tutti gli altri non verranno elaborati dal sito Web in modo da essere essenzialmente bianchi, elencando i nomi host accettabili.

Utilizzando l'approccio Riscrivi URL (o simili), è necessario aggiungere una nuova regola per ogni richiesta "cattiva". Questo non è un buon modello di supporto (cioè whack-a-mole) perché non c'è modo di tenere il passo con le possibili combinazioni. Ad esempio, potrei registrare mysite.foo sul tuo IP e ora devi aggiungere una regola. Adottando l'approccio raccomandato e non utilizzando i collegamenti jolly, la richiesta non verrà nemmeno inviata a IIS perché non esiste un sito Web configurato per elaborare la richiesta.

La vulnerabilità menzionata proviene da siti Web configurati per accettare qualsiasi nome host. In tal modo consente a tale valore di popolare la variabile che non è più affidabile in quanto potrebbe essere qualsiasi cosa. Prendendo l'approccio solo con nomi host specifici vincolanti, assicuri che solo quei valori popoleranno la variabile e sono quindi affidabili.

score 0 · Answer 2

Per rispondere alla tua domanda originale, sì, l'URL riscrittura può ottenere ciò con IIS. URL Rewrite essenzialmente crea solo voci nel file web.config su /wwwroot/web.config (o lo crea se non esiste già).

Il web.config può essere manipolato manualmente per aggiungere le regole di iniezione host, ma IIS non saprà leggere il web.config a meno che non sia installato URL Rewrite. Il sito Web non verrà avviato. Quindi URL Rewrite deve essere installato anche se si desidera utilizzare uno script o un processo manuale per aggiornare il / i server.

Le seguenti regole indicano l'intestazione HTTP_HOST se non è "10.141.13.170" e non è "253.23.65.155" e non è "website.com", quindi interrompe la richiesta. Le voci multiple consentono di adattare un IP interno e un IP esterno e un nome di dominio, ad esempio.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Host_Injection_Prevention_Rule_1" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="10.141.13.170" negate="true" />
            <add input="{HTTP_HOST}" pattern="253.23.65.155" negate="true" />
            <add input="{HTTP_HOST}" pattern="website.com" negate="true" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

score 0 · Answer 3

La tua domanda è del 2015, ma nel 2018 Microsoft ha rilasciato un avviso sulla sicurezza [0] [1] che indicava il problema che sospettavi di avere. Per citare l'avviso:

For example, if IIS is configured to respond to requests for contoso.com or *.contoso.com hosts, the application is protected.

If IIS is configured to respond to any request from any host, the application is vulnerable.

[...]

Affected Software

Any ASP.NET Core hosted application which is directly exposed to the internet, or hosted behind a proxy which does not validate or restict host headers to known good values.

[0] link
[1] link