Come può un'applicazione Web proteggere gli utenti quando il browser non supporta l'HSTS?

Non puoi.

Il meglio che puoi fare è usare SSL in tutto il sito. Tutte le connessioni HTTP devono reindirizzare immediatamente l'utente a HTTPS (reindirizzarlo alla prima pagina tramite HTTPS, ad esempio http://www.example.com/anything.html deve reindirizzare a https://www.example.com/ ). Non pubblicare alcun contenuto su HTTP (a parte un reindirizzamento immediato alla tua pagina principale, su HTTPS). Imposta il flag secure su tutti i cookie (ovviamente).

Questo non fermerà un attacco man-in-the-middle che declassifica l'utente su HTTP. Senza HSTS, non puoi impedire questo tipo di attacco.

Non puoi fare di meglio. Oh bene. È proprio come va con IE.

Vedi anche Opzioni per la difesa contro SSLstrip? .

Ovviamente non c'è modo per te di prevenire un attacco che potrebbe accadere prima il traffico arriva anche al tuo server. Non sei in grado di avere alcun effetto a quel punto.

Tuttavia, una cosa che puoi fare per evitare che il traffico non SSL venga mai inviato è quello di interrompere intenzionalmente i collegamenti non SSL. Dato che i webmaster testeranno i loro collegamenti almeno una volta prima di andare in diretta, ciò li indurrà a capire che devono cambiare il loro protocollo in https.

Un modo semplice per farlo è quello di mostrare una pagina che avverte l'utente che sono arrivati tramite un link non sicuro e ordina loro di "aggiornare i loro segnalibri" ecc, e quindi fornisce un link https per procedere dove volevano partire. È abbastanza poco intrusivo e non ostacola troppo gli utenti normali , ma dà il suggerimento ai web designer che sono comunque l'obiettivo di questo tipo di campagna.

Probabilmente vuoi dare a questa pagina un codice di stato 404 in modo che non venga interpretato come contenuto reale. Il rovescio della medaglia è che i motori di ricerca si basano su un reindirizzamento 302 per aggiornare il loro indice in modo che punti alla pagina corretta. Restituendo un 404 si rimuoverà il collegamento dall'indice invece di aggiornarlo su https. Quindi potresti voler inviare bot a 302 e inviare browser alla pagina 404 "aggiorna i tuoi link".

L'HSTS è l'unica protezione contro SSLStrip, tuttavia puoi prendere le seguenti precauzioni per aiutare a prevenire gli attacchi:

1. Assicurati che la tua applicazione web sia priva di vulnerabilità dei Contenuti Misti . Questo va oltre l'HSTS perché non protegge contro l'estrazione di JavaScript su HTTP da altri domini.

2. Una soluzione comune ai problemi di sicurezza è EDUCATION . Fornire un messaggio non invadente agli utenti che stanno utilizzando un browser non sicuro e che dovrebbero prendere in considerazione l'utilizzo di Chrome o Firefox.

3. Imposta il flag "sicuro" sui cookie http (ma tutti dovrebbero farlo comunque e non blocca SSLStrip).

4. Introduci JavaScript in ogni pagina che rileva se la pagina è stata caricata su HTTP (il che dovrebbe essere impossibile a causa dell'HSTS) e impedisce all'utente di utilizzare la tua applicazione web. Mostra un'enorme finestra ROSSA che dice SEI SOTTO ATTACCO . Questo potrebbe essere rimosso con un attacco MITM mirato, ma non se l'attaccante sta usando ciecamente SSLStrip.

La prima cosa che mi viene in mente è impostare il server in modo che accetti solo connessioni SSL nelle pagine pertinenti e non permetta connessioni HTTP. Ciò dovrebbe impedire al server di inviare qualsiasi cosa sensibile all'utente in chiaro, ma in definitiva non fermerà un MITM attivo che può creare una connessione non sicura all'utente, ma poi convertirlo in una connessione SSL dall'attaccante al server .

In definitiva non sono sicuro che ci sia molto di più che si può fare, anche se, dato che senza un meccanismo per informare il cliente che non dovrebbero inviare roba in chiaro, accetteranno qualunque cosa siano ha detto.

Questo fa emergere un altro punto, non so molto sull'HSTS ma sembra che un attaccante attivo possa impedire che la comunicazione diretta tra l'host e il client possa anche semplicemente rimuovere l'HSTS dal momento che HTTPS non viene normalmente usato con un certificato cliente All'inizio l'utente non vedrebbe una connessione sicura, ma se non ci si fida che l'utente sappia cosa dovrebbe o non dovrebbe essere HTTPS, allora, in realtà, probabilmente non sarebbe un grosso sforzo per qualcosa che potremmo aggiungere controllare che anche HTTPS sia spogliato.

Suppongo che un'altra idea sarebbe quella di inserire una sorta di chiamata JavaScript che controllerebbe il tipo di connessione e mostrerebbe un avvertimento, ma, ancora una volta, questo potrebbe potenzialmente essere rimosso da un attaccante attivo. link