Utilizzo della funzione di reindirizzamento HTTP tramite l'intestazione Host

Questa è una vecchia domanda, ma per motivi di completezza aggiungerei alcuni pensieri.

L'attacco di headers di riferimento in termini di host è Attacchi di intestazione Host pratici (2013 ) ed è ancora valido.

Gli hacker sarebbero certamente il trucco uri assoluto per iniettare l'header sbagliato e assicurarsi di raggiungere il giusto virtualhost. Ma in alcuni casi questo è nemmeno richiesto (come forse nella tua attuale applicazione, dove qualsiasi richiesta con qualsiasi intestazione di Host è accettata dato che la query HTTP è fatta sull'IP corretto)

# instead of
  GET /uri HTTP/1.1
  Host: good.name.com
# they would use
  GET http://good.name.com/uri HTTP/1.1
  Host: evil.com

E questo potrebbe essere sfruttato principalmente in 3 modi (principalmente, ma questo è aperto a più idee):

• avvelenamento della cache : se l'applicazione alimenta la pagina con un dominio prelevato dalla richiesta (quando si ricostruiscono URL assoluti nei collegamenti html), è possibile che questi domini non validi terminino nella versione cache della pagina per %codice%. Abbastanza difficile da eseguire (la cache potrebbe finire con il caching della pagina come /uri e non http://good.name.com/uri .
• link non validi nella email : indica che la tua applicazione sta inviando un link one-time di reimpostazione della password, con l'url estratto dall'intestazione host, quindi l'utente malintenzionato potrebbe sperare che qualcuno faccia clic sul link con il dominio evil.com . Significa che qualcuno fa clic su un link email di reimpostazione della password senza chiedere la reimpostazione della password (poiché l'autore dell'attacco ha eseguito la query errata)
• Iniezione CRLF , come con tutte le intestazioni iniettate, un obiettivo potrebbe essere ottenere una risposta in cui una voce host molto negativa (contenente /uri o CRLF , ovvero "\ r \ n") essere riutilizzato senza filtrare le intestazioni di risposta. Iniezione alle intestazioni nella risposta.

Come @Steffen Ullrich ha osservato che non c'è modo di guidare un utente innocente per eseguire l'attacco (soprattutto perché il browser usa la risoluzione DNS del nome host per trovare l'IP del server web). Quindi l'unica vittima sembra essere l'autore dell'attacco . Ma comunque, l'obiettivo di attacco è asincrono. Non è come un attacco xss, l'obiettivo non è l'utente che riceve la risposta. In cache poising è abbastanza ovvio (l'obiettivo è la cache), l'e-mail di reimpostazione della password viene utilizzata per portare l'attacco alla vittima e nell'iniezione di CRLF si inserisce la contraffazione della divisione della risposta HTTP e dell'HTTP zone, dove le conseguenze sono piuttosto complicate, ma possono portare a avvelenamento della cache, negazione del servizio, avvelenamento da socket, richieste incomplete, ecc. La destinazione è un proxy inverso e l'attacco verrà successivamente esteso ad altri utenti tramite questo proxy.

Non è possibile inviare un'intestazione Host personalizzata dal browser, il che significa che non è possibile sfruttarlo utilizzando solo un browser. E poiché HTTPS viene utilizzato, non è possibile montare un uomo nell'attacco intermedio per modificare l'intestazione host di una richiesta esistente. Ma anche se HTTPS non dovesse essere utilizzato, non si guadagna nulla di nuovo modificando l'intestazione Host nella richiesta, poiché come un uomo nel mezzo si potrebbe comunque modificare l'intestazione Location nella risposta.

In sintesi, dubito che il problema riscontrato possa essere utilizzato per qualcosa di malevolo, almeno non quando si utilizza il browser come client.