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

Oltre alle eccellenti risposte di @ GZBK e @ Adnan, un'altra cosa che ho pensato è che l'applicazione è vulnerabile a XSS sull'output di un valore del cookie.

Di solito il valore del cookie viene emesso non codificato, 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 attaccare se stesso. Tuttavia, se la richiesta HTTP è stata intercettata e il cookie è stato avvelenato con un exploit per questo XSS vulnerabilità, questo potrebbe essere un possibile vettore di attacco in questo scenario.

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

can I trust that from now on my session is not vulnerable to any man-in-the-middle attack?

L'unico modo veramente sicuro per navigare su una rete non sicura è disabilitare tutti i protocolli dal browser diversi da HTTPS (ad esempio, configurare un proxy locale ma impostare il browser affinché utilizzi una porta non valida per tutti i protocolli diversi da HTTPS). L'HSTS può essere d'aiuto, ma se la prima richiesta viene intercettata (ad esempio utilizzando la tecnica descritta qui prima ancora di aver pensato di visitare " example.com ") sarai comunque vulnerabile.

Aggiornamento di seguito in relazione alla nuova domanda nel commento:

[I forgot to enter the bounty comment] I'm asking from the perspective of a user (though it is interesting to know what the site/app should be doing, too). In what circumstances does typing example.com in the browser's URL bar directly direct me to https://example.com/? In what circumstances does typing http://example.com/ directly direct me to https://example.com/? If there is a request to http://example.com/ first, what bad things can happen, and how as a user can I know whether bad things are happening? – Gilles

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

When a web application issues HSTS Policy to user agents, conformant user agents behave as follows: Automatically turn any insecure links referencing the web application into secure links. (For instance, http://example.com/some/page/ will be modified to https://example.com/some/page/ before accessing the server.) If the security of the connection cannot be ensured (e.g. the server's TLS certificate is self-signed), show an error message and do not allow the user to access the web application.

Se non ci sono stati record HSTS e l'utente ha digitato "example.com" o "http://example.com" nella barra degli indirizzi un insicuro prima sarebbe stata fatta la richiesta a " http://example.com " che normalmente rispondeva con l'intestazione " Location: https://example.com/ ". Ciò farà sì che il browser carichi l'URL HTTPS. Se l'utente desiderava assicurarsi che nulla fosse stato iniettato o modificato e che tutto ciò che accadeva era che l'intestazione " Location " è stata restituita, dovrebbero cancellare tutte le informazioni di stato. Il processo per fare ciò 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 browser. Questo assicurerà che non ci sia uno script in esecuzione che sta impostando i cookie su un intervallo. Ad esempio, se esiste una vulnerabilità XSS attraverso un valore del cookie, lo script inserito potrebbe garantire il valore del cookie rimane impostato resettandolo ogni pochi secondi. AKA un cookie zombie .
3. Cancella i cookie, qualsiasi archivio locale e qualsiasi dato del plug-in del browser (ad esempio, Flash / Silverlight locale). Ciò rimuoverà la maggior parte delle informazioni di stato per il sito.
4. Premere Aggiorna sul browser. Ciò garantirà che il caricamento della pagina corrente non sia un POST perché l'utente riceverà un messaggio di avviso. Il POST può aver inserito il contenuto nella pagina se ci sono delle vulnerabilità XSS .
5. Riattiva JavaScript se necessario.

Ovviamente questo è molto da fare e potrebbe essere più facile 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 sta navigando su una rete non sicura, non può mai essere sicuro al 100%. Non esiste un controllo facile per la manomissione a meno che tutto non sia in uno stato noto (quindi a partire da uno stato pulito / HTTPS o rimuovendo tutte le informazioni di stato). Sì, potevano controllare manualmente i cookie, ma con tecniche intelligenti un utente malintenzionato potrebbe cancellare il cookie una volta che lo script è stato incorporato nella pagina.

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

• La bandiera protetta non è impostata. 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'utente malintenzionato avrà accesso alla sessione.

• La richiesta HTTP iniziale viene intercettata e la risposta viene sostituita con una che pianta un cookie con un identificativo di sessione per una sessione avviata dall'hacker. 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, in quanto la sessione può essere quella legittima avviata dall'utente.

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

Come menzionato sopra, tutti i cookie devono essere contrassegnati come protetti ( Owasp ), ma anche se ti aspetti che il tuo gli utenti possono accedere al tuo sito solo tramite SSL, quindi devi abilitare HTTP Strict Transport Security (HSTS - Wikipedia ).

Il primo garantirà che nessun cookie verrà inviato tramite una connessione HTTP chiara, quest'ultimo garantirà che qualsiasi browser compatibile, sempre dopo un primo accesso iniziale, utilizzi HTTPS per accedere al sito Web (anche quando l'utente digita HTTP, il browser lo sostituirà automaticamente da HTTPS senza inviare alcuna richiesta HTTP al server).

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à), allora l'utente ha, tramite il tuo certificato SSL e i suoi certificati di root attendibili, verificato che la pagina ha caricato dal tuo server arrivato senza manomissioni.

Vedo i seguenti trucchi:

1. Un attacco man-in-the-middle è ovviamente possibile se l'intercettore può falsificare il certificato SSL. Quindi, se lo hai condiviso (con il tuo CDN? Con l'amministratore di ladri del tuo web hoster? Con il collega che è legalmente proibito di ammettere che è stato citato in giudizio per le chiavi?), Questo è in realtà un possibile vettore di attacco. Potrebbe anche accadere se tu generassi le chiavi deboli in primo luogo (forse il tuo sistema era basso di entropia o usato un generatore di numeri casuali rotto?).

2. Non è possibile che una singola CA radice configurata per il trust possa essere compromessa. Nota che in genere ce ne sono molti e molti e per il man-in-the-middle è necessario un solo compromesso per falsificare un certificato SSL apparentemente valido per il tuo dominio. Si noti inoltre che alcuni utenti potrebbero essere a capriccio del loro fornitore che potrebbe (come Microsoft) spingere su richiesta nuovi certificati CA radice, consentendo teoricamente qualsiasi attacco (legittimo?) Man-in-the-middle di Microsoft (o di qualsiasi CA ) può essere persuaso a sostenere. Possiamo, naturalmente, sperare che solo i bravi ragazzi abbiano così tanto potere sulle corporazioni.

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

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

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

1) Invia reindirizzamenti 301/302 agli URL intermedi per configurare / installare malware al di fuori del browser. Questo può includere keylogger, ecc. Molto prezioso in quanto l'attaccante può "scegliere le vittime" andando su un sito di interesse. Quando il malware viene distribuito sulla destinazione, un reindirizzamento del browser finale viene inviato come previsto al client e il filmato continua come se nulla fosse accaduto.

2) Usa lo stesso veicolo per attaccare il browser stesso. Vi è l'opportunità qui 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 fuga di informazioni attraverso un canale nascosto come suggerimenti di ricerca o completamento di parole chiave. Oppure combinalo con l'opzione 1 e configura il browser in modo che esegua il proxy SSL tramite codice in esecuzione localmente.

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

C'è una vasta gamma di difficoltà negli scenari di cui sopra e tutti si basano più o meno sui punti deboli in particolari versioni del browser. Molti degli scenari possono essere più difficili di altri vettori di attacco più facili. Esiste l'utilità di utilizzare exploit focalizzati in base alle 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 di esposizione che può aprire una sessione iniziale da HTTP a HTTPS.