Non puoi impedire che i cookie inviino inviati via HTTP la prima volta, ma puoi prendere provvedimenti per ridurre al minimo il danno che potrebbe essere causato da questo. Il principio di base è che non si onora mai nulla di ciò che viene inviato tramite HTTP e ogni volta che si ricevono informazioni sensibili in testo non crittografato, le informazioni vengono considerate come compromesse.
Imposta il tuo sito per reindirizzare da HTTP a HTTPS e iniziare a inviare intestazioni di Strict-Transport-Security. (Non devi andare per il precarico finché non sei bravo e pronto, quello che sto per dire funzionerà a prescindere.)
Quindi, ogni volta che vedi i cookie inviati tramite testo non crittografato HTTP, invalida tutti questi cookie sul lato server. Non tentare di eliminarli dal barattolo dei cookie del browser a questo punto, perché non è garantito che funzioni per diversi motivi (un messaggio in chiaro la risposta HTTP non può manipolare i cookie codificati Secure, i browser più vecchi potrebbero ignorare max-age = 0 , il man-in-the-middle potrebbe eliminare del tutto Set-Cookie al fine di mantenere la vittima usando il cookie compromesso). Ma non onorarli quando compaiono in una richiesta HTTPS successiva. A quel punto (vale a dire solo quando è stato stabilito un canale sicuro), emettere un nuovo token di sessione e richiedere all'utente di eseguire nuovamente l'accesso.
Allo stesso modo, se vedi il tuo modulo di accesso presentato in testo non chiaro, non invalida semplicemente il cookie di sessione, blocca l'account . Non reindirizza il recupero dell'account, il login o il modulo di registrazione da HTTP a HTTPS; invia invece un messaggio di errore, istruendo l'umano a correggere l'URL a mano (è come un captcha, ma è per aggirare la riscrittura dell'URL in sslstrip ;-). E qualsiasi pagina che dovrebbe essere accessibile solo agli utenti che hanno effettuato l'accesso dovrebbe reindirizzare alla pagina principale, non a HTTPS stesso, quando vi si accede tramite cleartext.
Inoltre, assicurati che i tuoi cookie di sessione siano entrambi non rimborsabili e privi di significato . La maggior parte dei framework Web lo farà automaticamente al giorno d'oggi, ma se non ne hai uno, la costruzione più semplice che funzionerà è: ogni cookie di sessione è un numero casuale di grandi dimensioni (64 bit potrebbe essere sufficiente, 128 è abbastanza) generato da un RNG crittograficamente sicuro , più un messaggio di autenticazione del codice che firma quel numero. È possibile utilizzare un MAC simmetrico per questo, poiché il cookie deve solo essere autenticato dal sito, che è la stessa entità che ha emesso il MAC, quindi conoscerà lo stesso segreto entrambe le volte. Se un cookie arriva con un MAC non valido, ignoralo , indipendentemente da come lo hai ottenuto - fai finta di non averlo mai capito. (Questo addirittura sostituisce la regola sull'invalidazione dei cookie che arrivano su HTTP. Non vuoi che l'aggressore sia in grado di forzare la disconnessione delle persone forgiando le richieste.) Ma se il MAC è valido, allora usi il numero casuale come chiave per una tabella di database che registra tutte le informazioni effettive associate a una sessione utente.
È inoltre buona norma non emettere alcun cookie fino a quando qualcuno non tenta di accedere. Ciò rende molto più difficile per un MITM mettere le mani su un cookie valido, e rende anche più facile per te rispettare GDPR.
Dopo aver letto la discussione sulle altre risposte, mi rendo conto che l'OP si occupa di uno scenario molto particolare: un nuovo utente al sito lo accede per la prima volta attraverso un uomo-in- the-middle, che sta terminando l'HTTPS, estraendo HSTS e riscrivendo tutti i link e inoltrando il sito in chiaro all'ipotetico nuovo utente. Contro questo, infatti, l'unica cosa che può aiutare è il precarico dell'HSTS. In assenza del precarico HSTS, l'account del nuovo utente sarà "nato compromesso", per così dire, e l'attaccante conoscerà tutto su di esso: non solo il cookie di sessione, ma il nome utente e la password, e l'indirizzo email utilizzato per il recupero dell'account e ogni bit di informazioni personali inserite dalla vittima. Questo è brutto e, ahimè, più plausibile di quanto tu possa pensare.
Ma se hai solo una possibilità di interagire con l'utente su un canale che non viene attivamente manomesso, puoi spingere HSTS e cookie di sessione sicuri e tutti i consigli sopra riportati saranno utili.