No puede evitar que las cookies se envíen a través de HTTP la primera vez, pero puede tomar medidas para minimizar el daño que podría causar esto. El principio básico es que nunca honras nada enviado a través de HTTP, y siempre que recibas información confidencial en texto claro, tratas esa información como comprometida.
Configure su sitio para redireccionar de HTTP a HTTPS y comience a enviar encabezados de seguridad de transporte estricto. (No tiene que ir a la precarga hasta que esté bien y listo; lo que voy a decir funcionará a pesar de todo.)
Luego, cuando vea que las cookies se envían a través de HTTP de texto simple, invalide todas esas cookies en el lado del servidor. No intente sacarlos del contenedor de cookies del navegador en este momento, ya que no se garantiza que funcione por varias razones (una respuesta HTTP de texto no puede manipular las cookies etiquetadas como Seguras, los navegadores más antiguos pueden ignorar max-age = 0 , el hombre en el medio puede eliminar el Set-Cookie por completo para mantener a la víctima usando la cookie comprometida). Pero no los honre cuando aparezcan en una solicitud HTTPS posterior. En ese momento (es decir, solo cuando haya establecido un canal seguro), emita un nuevo token de sesión y solicite al usuario que vuelva a iniciar sesión.
De manera similar, si ve que su formulario de inicio de sesión se envía en texto simple, no solo invalide la cookie de sesión, bloquee la cuenta . No redirige el formulario de recuperación, inicio de sesión o registro de la cuenta de HTTP a HTTPS; en su lugar, emita un mensaje de error, indicando a la persona que arregle la URL a mano (es como un captcha, pero para omitir la reescritura de URL en sslstrip ;-)). Y cualquier página que debería ser accesible solo para usuarios registrados debe redirigirse a la página principal, no a HTTPS en sí, cuando se accede a través de texto simple.
Además, asegúrese de que las cookies de su sesión sean no reconocibles y sin sentido . Hoy en día, la mayoría de los frameworks web lo harán por usted automáticamente, pero si no tiene uno, la construcción más simple que funcionará es: cada cookie de sesión es una grande (64 bits pueden ser suficientes, 128 es definitivamente suficiente) número aleatorio, generado por un RNG criptográficamente seguro , más un código de autenticación de mensaje firmando ese número. Puede usar un MAC simétrico para esto, porque la cookie solo debe ser autenticada por el sitio, que es la misma entidad que emitió el MAC, por lo que sabrá el mismo secreto en ambas ocasiones. Si llega una cookie con un MAC no válido, ignóralo , independientemente de cómo lo obtuviste, finge que nunca lo obtuviste. (Esto incluso reemplaza la regla sobre la invalidación de cookies que llegan a través de HTTP. No quiere que el atacante pueda forzar el cierre de sesión de las personas falsificando solicitudes). Pero si el MAC es válido, entonces use el número aleatorio como el clave para una tabla de base de datos que registra toda la información real asociada con una sesión de usuario.
También es una buena práctica no emitir cookies hasta que alguien intente iniciar sesión. Eso hace que sea mucho más difícil para un MITM obtener una cookie válida, y también hace que sea más fácil para usted cumplir. GDPR.
Después de leer la discusión sobre las otras respuestas, ahora me doy cuenta de que OP se ocupa de un escenario muy particular: un nuevo usuario al sitio accede a él por primera vez a través de un man-in the-middle, que está terminando HTTPS, eliminando HSTS y reescribiendo todos los enlaces, y transmitiendo el sitio sin cifrar al hipotético nuevo usuario. Contra esto, de hecho, lo único que puede ayudar es la precarga de HSTS. En ausencia de la precarga de HSTS, la cuenta del nuevo usuario "nacerá comprometida", por así decirlo, y el atacante sabrá todo al respecto: no solo la cookie de sesión, sino el nombre de usuario y la contraseña, y la dirección de correo electrónico utilizada para la recuperación de la cuenta, y toda la información personal que ingresó la víctima. Esto es desagradable y, por desgracia, más plausible de lo que piensas.
Pero si solo tiene una oportunidad de interactuar con el usuario a través de un canal que no está siendo manipulado activamente, puede insertar HSTS y cookies de sesión seguras y todos los consejos anteriores serán útiles.