it-swarm.dev

Sicurezza di un reindirizzamento iniziale da http://example.com a https://example.com

Supporre che http://example.com/<foo> reindirizza sistematicamente a https://example.com/<foo>. Io entro http://example.com nella barra dell'URL del mio browser e vedo un caricamento della pagina e la barra dell'URL ora mostra esattamente https://example.com/ (nessun hack Unicode, nessun hack spazi bianchi, ecc.). Verifico che questo sia il caso (la maggior parte degli utenti non lo farà, ma presumo che in questo caso sia stato l'utente). Supponi inoltre che il mio browser non sia vulnerabile a falsificazione della barra degli URL . Supponi anche che il certificato SSL sia valido.

In questa situazione, posso fidarmi che d'ora in poi la mia sessione non sarà vulnerabile a nessun attacco man-in-the-middle? Un MITM sulla connessione HTTP iniziale potrebbe aver iniettato qualcosa - un cookie, un frame nascosto, qualunque cosa possa compromettere la successiva sessione HTTPS apparente?

Questa è una sotto-lettera di Quanto è sicuro reindirizzare l'utente da http://normal.bank.com a https://secure.bank.com ? maggiori dettagli per questo caso specifico.

Oltre alle eccellenti risposte di @ GZBK e @ Adnan, un'altra cosa a cui ho pensato è il caso in cui l'applicazione sia vulnerabile a XSS all'output di un valore del cookie.

Supponiamo che normalmente il valore del cookie venga emesso senza codifica, ma poiché il cookie era normalmente impostato su HTTPS e non sarebbe soggetto al MITM, non era un pericolo in quanto l'utente poteva solo attaccarsi. Tuttavia, se la richiesta HTTP è stata intercettata e il cookie è stato avvelenato con un exploit per questa vulnerabilità XSS , questo potrebbe essere un possibile vettore di attacco in questo scenario.

Ovviamente questa non è la richiesta non HTTPS che include un reindirizzamento vulnerabile perché questo cookie potrebbe essere impostato anche se "example.com "non ha ascoltato affatto sulla porta 80: un utente malintenzionato potrebbe MITM qualsiasi altra richiesta HTTP effettuata dalla vittima, reindirizzandola a" http://example.com "che anche l'attaccante intercetta e restituisce la risposta per reindirizzare l'utente al sito Web originale, ma solo dopo" example.com "il cookie è stato avvelenato.

posso fidarmi che d'ora in poi la mia sessione non sarà vulnerabile ad alcun attacco man-in-the-middle?

L'unico modo veramente sicuro per navigare su una rete non attendibile è disabilitare tutti i protocolli dal browser diversi da HTTPS (ad es. Configurare un proxy locale ma impostare il browser in modo che utilizzi una porta non valida per tutti i protocolli diversi da HTTPS). HSTS può essere d'aiuto, ma se la prima richiesta viene intercettata (ad es. Utilizzando la tecnica qui descritta anche prima ancora di aver pensato di visitare "example.com ") saresti ancora vulnerabile.

Aggiornamento di seguito in relazione alla nuova domanda nel commento:

[Ho dimenticato di inserire il commento sulla generosità] Sto chiedendo dal punto di vista di un utente (anche se è interessante sapere cosa dovrebbe fare anche il sito/app). In quali circostanze digitando example.com nella barra degli URL del browser mi viene indirizzato direttamente a https://example.com/ ? In quali circostanze la digitazione http://example.com/ mi indirizza direttamente a https://example.com/ ? Se c'è una richiesta di http://example.com/ prima, quali cose brutte possono accadere e come utente posso sapere se stanno accadendo cose cattive? - Gilles

Se era attivo un record HSTS per "example.com "(precaricato o se l'utente aveva già visitato) e l'utente ha digitato "example.com" o "http://example.com" nella barra degli indirizzi andrebbero direttamente a "https://example.com" senza alcuna richiesta effettuata su HTTP.

Quando un'applicazione Web invia la politica HSTS agli agenti utente, gli agenti utente conformi si comportano nel modo seguente: Trasforma automaticamente tutti i collegamenti non sicuri che fanno riferimento all'applicazione Web in collegamenti sicuri. (Ad esempio, http://example.com/some/page/ verrà modificato in https://example.com/some/page/ prima di accedere al server .) Se non è possibile garantire la sicurezza della connessione (ad es. Il certificato TLS del server è autofirmato), mostrare un messaggio di errore e non consentire all'utente di accedere all'applicazione Web.

Se non è stato registrato HSTS record e l'utente ha digitato "example.com" o "http://example.com" nella loro barra degli indirizzi una richiesta non sicura verrebbe prima fatta a "http://example.com "che normalmente risponderebbe con" Location: https://example.com/ "header. Questo causerà il caricamento dell'URL HTTPS da parte del browser. Se l'utente voleva assicurarsi che non fosse stato iniettato o modificato nulla e che tutto ciò che accadeva fosse che fosse restituita l'intestazione" Location ", avrebbe dovuto cancellare tutte le informazioni sullo stato. Il processo per farlo dovrebbe essere il seguente:

  1. Chiudi tutte le altre finestre e schede del browser: questo assicurerà che nessun'altra richiesta HTTP sia MITM e reindirizzata a "example.com".
  2. Disabilita JavaScript nel loro browser. Questo assicurerà che non ci siano script in esecuzione che impostano i cookie su un intervallo. Ad esempio, se c'era una vulnerabilità XSS attraverso un valore del cookie, lo script iniettato potrebbe garantire che il valore del cookie rimanga impostato ripristinandolo ogni pochi secondi. AKA un cookie di zombi .
  3. Cancella cookie, qualsiasi spazio di archiviazione locale e dati di plug-in del browser (ad esempio Flash/Silverlight locale). Ciò rimuoverà la maggior parte delle informazioni sullo stato del sito.
  4. Premi aggiorna sul browser. Questo assicurerà che il caricamento della pagina corrente non fosse un POST perché l'utente avrebbe ricevuto un messaggio di avviso. Il POST potrebbe aver iniettato contenuto nella pagina se ci sono qualsiasi vulnerabilità XSS .
  5. Riattiva JavaScript, se necessario.

Ovviamente questo è molto da affrontare e potrebbe essere più semplice per loro semplicemente utilizzare la tecnica proxy come descritto in precedenza per disabilitare HTTP e iniziare con un browser pulito (ad esempio una nuova sessione di navigazione in incognito).

Se un utente naviga su una rete non attendibile, non può mai essere sicuro al 100%. Non esiste un controllo facile per manomissione a meno che tutto non sia in uno stato noto (quindi a partire da uno stato pulito/HTTPS o rimuovendo tutte le informazioni sullo stato). Sì, potrebbero controllare manualmente i cookie, ma con tecniche intelligenti un utente malintenzionato potrebbe cancellare il cookie una volta che lo script è stato incorporato nella pagina.

7
SilverlightFox

Per quanto posso vedere, ci sono due vulnerabilità qui:

  • Secure flag non è impostato. La richiesta HTTP iniziale perderà il cookie di sessione da una sessione creata dall'istanza in http://example.com o da una sessione precedente creata dall'istanza in https://example.com. Lo stesso identificatore di sessione trapelato verrà riutilizzato -> L'attaccante avrà accesso alla sessione.

  • La richiesta HTTP iniziale viene intercettata e la risposta viene sostituita con una che pianta un cookie con un identificatore di sessione per una sessione avviata dall'aggressore. Le richieste successive riutilizzeranno lo stesso cookie. Questa è una forma di attacchi di fissazione della sessione .

In entrambi i casi, quando si raggiunge l'istanza HTTPS, il server non ha modo di sapere se invalidare la sessione precedente o meno, poiché la sessione può essere quella legittima avviata dall'utente.

L'unica soluzione che vedo qui è invalidare e ricreare la sessione quando viene effettuata una richiesta a https://example.com e quindi utilizza token crittograficamente avanzati oltre al cookie di sessione con richieste successive. Il token deve essere utilizzato una volta e una sola volta.

11
Adi

Come accennato in precedenza, tutti i cookie devono essere contrassegnati come Sicuro ( Owasp ), ma anche se ti aspetti che i tuoi utenti accedano al tuo sito solo tramite SSL, dovresti abilitare HTTP Strict Transport Security (HSTS - - Wikipedia ).

Il primo assicurerà che nessun cookie verrà inviato su una chiara connessione HTTP, il secondo assicurerà che qualsiasi browser compatibile, sempre dopo un primo accesso iniziale, utilizzerà HTTPS per accedere al sito Web (anche quando l'utente digita HTTP, il browser sostituirlo automaticamente con HTTPS senza inviare alcuna richiesta HTTP al server).

11
WhiteWinterWolf

Poiché la richiesta iniziale è stata inviata su HTTP; esiste un gran numero di possibili vettori di attacco disponibili che non dipendono dai cookie o dallo stato della sessione e non sarebbero interessati da un successivo reindirizzamento a HTTPS, anche con un'intestazione HSTS fornita dal server.

Anche se non sono uno specialista della sicurezza Web a tempo pieno, ecco un elenco di possibili attacchi resi possibili quando un utente malintenzionato è in grado di eseguire il MITM della richiesta HTTP originale.

1) Invia reindirizzamenti 301/302 a URL intermedi per impostare/installare malware al di fuori del browser. Questo può includere keylogger, ecc. Molto prezioso in quanto l'aggressore può "raccogliere ciliegie" sulle vittime che visitano un sito di interesse. Quando il malware viene distribuito sul target, un reindirizzamento finale del browser viene inviato come previsto al client e il film continua come se nulla fosse successo.

2) Usa lo stesso veicolo per attaccare il browser stesso. Qui c'è la possibilità per l'attaccante di eseguire azioni specifiche del browser come l'installazione di un plugin dannoso.

3) Come sopra, ma sfrutta tutti i buchi disponibili per modificare la configurazione del browser. Questo potrebbe essere usato per abilitare la perdita di informazioni attraverso un canale nascosto come suggerimenti di ricerca o completamento delle parole chiave. In alternativa, combinalo con l'opzione 1 e configura il browser come proxy SSL attraverso l'esecuzione del codice in locale.

4) Carica la pagina SSL di destinazione in un iframe e sfrutta i punti deboli XSS per ottenere e sfruttare le credenziali di sessione una volta che la vittima ha effettuato l'accesso.

Vi è una vasta gamma di difficoltà negli scenari di cui sopra e si basano tutti più o meno sui punti deboli in particolari versioni del browser. Molti scenari possono essere più difficili di altri vettori di attacco più facili. Esiste l'utilità di utilizzare exploit mirati a seconda delle informazioni disponibili nelle intestazioni della richiesta originale, come user-agent, che potrebbero essere interessanti.

Sono sicuro che ci sono altre ampie categorie di attacchi che mi mancano, ma questo è un inizio all'esposizione che può aprire una sessione iniziale da HTTP a HTTPS.

1
bizzyunderscore

Seguendo la tua premessa che la connessione SSL è stata stabilita con il dominio corretto (e supponendo che né il tuo server né il browser abbiano alcuna vulnerabilità), l'utente ha verificato, tramite il tuo certificato SSL e i suoi certificati radice attendibili, che la pagina da cui ha caricato il tuo server è arrivato senza manomissioni.

Vedo i seguenti gotcha:

  1. Un attacco man-in-the-middle è ovviamente possibile se l'interceptor può falsificare il tuo certificato SSL. Quindi, se l'hai condiviso (con la tua CDN? Con l'amministratore canaglia del tuo web hoster? Con il collega a cui è legalmente proibito ammettere di essere stato citato per le chiavi?), Questo è in realtà un possibile vettore di attacco. Potrebbe anche accadere se in primo luogo hai generato chiavi deboli (forse il tuo sistema era a corto di entropia o hai usato un generatore di numeri casuali rotto?).

  2. Nessuna delle CA principali su cui il browser è configurato per essere attendibile potrebbe essere compromessa. Tieni presente che in genere ce ne sono molti e molti e un solo compromesso è richiesto affinché l'uomo nel mezzo forgi un certificato SSL apparentemente valido per il tuo dominio. Si noti inoltre che alcuni utenti potrebbero essere per capriccio del proprio fornitore che può (come Microsoft) inviare nuovi certificati CA radice su richiesta, teoricamente permettendo qualsiasi attacco (legittimo?) Man-in-the-middle che Microsoft (o una qualsiasi delle CA) ) può essere persuaso a sostenere. Naturalmente, possiamo sperare che solo i bravi ragazzi abbiano così tanto potere sulle società.

  3. Anche le vulnerabilità apparentemente non correlate possono ovviamente negare l'intero argomento, anche quelle che possono essere definite una funzionalità piuttosto che un bug: Immagina che il man-in-the-middle inizialmente serva una pagina Web su HTTP che fa passare il browser alla visualizzazione a schermo intero, e quindi imita una tipica finestra del browser. Il tuo ipotetico utente superdilligente noterà che la barra degli indirizzi e i suoi contenuti sono solo un'elaborata emulazione della barra degli indirizzi del suo browser ...?

1
pyramids