IIS e ASP sono vulnerabili agli stessi attacchi di intestazione host che abbiamo visto su Apache e Nginx? In particolare gli attacchi che utilizzano l'intestazione host HTTP per reimpostare una password o implementare l'avvelenamento della cache web. Questi attacchi specifici utilizzano le variabili SERVER e HOST.
Qualsiasi intuizione o aiuto è molto apprezzato.
L'intestazione "HOST" fa parte del protocollo http, le applicazioni vulnerabili sono vulnerabili perché inseriscono il valore di questa intestazione nel codice dell'applicazione senza una convalida adeguata, questo significa che non solo le applicazioni ospitate su Apache / Nginx possono essere vulnerabili. In breve, la risposta è sì, la tua applicazione potrebbe essere vulnerabile indipendentemente dal tipo di lingua / server che utilizzi. Evita di estrarre informazioni da questa intestazione, dato che manipolarle dal lato client è banale.
Sono d'accordo con Kotzu, avrei commentato, ma solo per poter pubblicare uno screenshot, sto postando questo come risposta.
Risposta breve:
Sì, gli attacchi alle intestazioni host sono possibili su stack IIS e ASP.NET.
Avvelenamento della reimpostazione della password: Ciò accade se il codice è scritto male, sul sito Web quando l'utente richiede un collegamento per reimpostare la password, il sito Web invia un collegamento con un token segreto all'indirizzo e-mail dell'utente.
Supponiamo che il link sia http (s): // [genuinesite] /resetpassword.aspx?someguid E guid sarebbe la chiave per un record nel database che sa per chi resettare la password.
Ma se il codice è stato scritto male per creare quel collegamento, userebbe Protocol + Host Header + "/resetpassword.aspx?" + guid,
quindi l'attaccante può facilmente passare l'intestazione host al proprio sito web,
Quindi la genuinità genererà e invierà e-mail con link come http (s): // [jenuinesite] /resetpassword.aspx?someguid
e l'autore dell'attacco avrebbe quel sito lì,
e sarebbe in grado di ottenere i parametri della stringa di query e di essere in grado di reimpostare la password per conto dell'utente, a condizione che l'utente in realtà faccia clic sul link dalla posta elettronica. E di solito lo fanno perché la posta elettronica viene realmente inviata da genuinesite.
Molti componenti software popolari hanno questa vulnerabilità.
Avvelenamento da cache:
La cache può essere avvelenata anche da HTTP Response Splinting, che di nuovo non è comune ormai da un giorno, ma qui stiamo parlando di Host Header.
Le cache ora sono a conoscenza dell'host, quindi con l'intestazione host se qualcuno tenta di avvelenare la cache, verrà tenuto separato dalla cache della genuinesite.
Fondamentalmente, mentre si genera (rendering) html, nel codice se in qualsiasi posto c'è un codice povero dove genera html / javascript basato su HOST, potrebbe essere vulnerabile. A patto che ci sia un qualche tipo di cache lato server o proxy del file html renderizzato.
Supponiamo che il codice stia generando html come Home , quindi manipolando l'intestazione host puoi renderlo come Home
E quella pagina verrà memorizzata nella cache lato server e l'utente malintenzionato può rubare i cookie di tutti gli utenti a cui viene fornita la pagina memorizzata nella cache.
Ovviamente, l'autore dell'attacco utilizzerà Pragma: no-cache per rimuovere prima la pagina effettivamente memorizzata nella cache e quindi posizionare la cache con la versione manipolata dell'intestazione host.
Ma come ho detto, in ASP.NET e nel mondo IIS non ho visto molto l'avvelenamento della cache con l'intestazione host, ma non sappiamo mai che la gente scrive sempre codice scadente.
Come possiamo evitare questo:
Penso che il modo più semplice (e una delle migliori pratiche) sia di avere impostazioni di binding corrette in IIS, anche se si ospita solo un sito Web con IIS.
Puoi persino avere più nomi host consentiti per un sito web.
In questo modo, se qualcuno cambia l'intestazione host, non raggiunge nemmeno il tuo sito web in IIS.
Leggi altre domande sui tag asp.net iis web-browser web-application attack-prevention