HSTS impidiendo los ataques de secuestro de cookies de MiTM

Si está visitando una página web por primera vez, incluso si utiliza HSTS, corre el riesgo de ataques MiTM ya que la conexión inicial se realiza a través de HTTP y se pueden usar herramientas como sslstrip para explotar eso (básicamente forzando que te quedes en HTTP). Pero si ya ha visitado una página anteriormente y su navegador es consciente de que se trata de una página HSTS, entonces sslstrip no funcionará.

La mayoría de los principales navegadores incluso tienen listas precargadas de algunos sitios HSTS, lo que significa que incluso si visita un sitio de esa lista por primera vez, estará protegido contra los ataques de MiTM.

  

cada página que estoy solicitando [...] también estará disponible a través de HTTPS, ¿verdad? Si no lo es, ¿HSTS no permitirá hacer una conexión HTTP?

Bien. Si habilita HSTS, debe ser compatible con HTTPS para todas las páginas. Si establece la directiva includeSubDomains, que se recomienda, todos los subdominios también deben ser compatibles con HTTPS.

  

a) Esto solo sucedería si el sitio web está disponible vi HTTP y HTTPS y se envía un redireccionamiento a la solicitud GET inicial del cliente y donde HSTS no está en su lugar (y ya tengo una cookie para ese sitio web) mi laptop), a la derecha

No. No importa lo que esté disponible. Incluso si no hay HTTP disponible, aún puede enviar la solicitud, revelando así la información a un hombre pasivo en el medio.

Un hombre activo en el medio también podría interceptar la solicitud HTTP, reenviarla como una solicitud HTTPS al servidor, leer la respuesta y enviarla de vuelta a usted como solicitud HTTP.

  

En un escenario en el que accedo a la misma página por primera vez desde una computadora diferente, incluso sin HSTS habilitado, no existe ningún riesgo porque todavía no tengo una cookie del servidor web, por lo que no habrá ninguna cookie. enviado con la solicitud inicial HTTP GET, ¿correcto?

Sí, si no envía información confidencial, no se expondrá información confidencial. Pero como se mencionó anteriormente, todavía no es seguro, ya que eres susceptible a un hombre activo en los ataques medios.

  

¿Pero esto no crearía una puerta para los ataques MiTM y el secuestro de cookies en el caso SOLAMENTE cuando el servidor web no envía una redirección al cliente pero continúa a través de HTTP? Quiero decir, en la solicitud GET HTTP inicial del cliente que no estamos enviando ninguna cookie, el servidor la envía, ¿por lo que el servidor web no la enviará al cliente a través de HTTPS?

Un hombre activo en el medio simplemente no puede enviarte la redirección a HTTPS, lo que te obliga a seguir comunicándote a través de HTTP.

Para un hombre pasivo en el medio, esto es principalmente cierto. Existe un problema si las cookies viven más tiempo que HSTS y el usuario no visitó la página por un tiempo. Luego, su primera solicitud puede ser a través de HTTP, revelando así una cookie.

Algunos de los problemas mencionados anteriormente se pueden evitar configurando su cookie como segura, por lo tanto, en primer lugar no permite enviarlos a través de HTTP.

MITM no es un problema

Si realmente es su primera visita a un sitio de HSTS, todavía no tendrá ninguna cookie. Tienes que visitar un sitio para que establezca una cookie para ti. Cuando lo haga, el sitio lo redirigirá inmediatamente a la versión https y, en el 99% de los casos, no habrá configurado una cookie (la redirección a https ocurre en el sentido ascendente de la lógica de la aplicación, por ejemplo, en las reglas de redireccionamiento en el firewall o en Preprocesamiento de IIS). Incluso si por alguna razón establece una cookie, si está destinada a ser segura, tendrá el indicador secure set, que le dice a su navegador que no presente la cookie a través de http.

La fijación de sesión es un problema

En esa llamada http inicial, puede golpear un sitio malicioso que actúe como MitM y puede establecer una cookie. En este caso, la cookie ya es conocida por el pirata informático, por lo que no existe ninguna preocupación sobre la filtración de ese valor de la cookie a una parte maliciosa. Sin embargo, existe otra preocupación: la cookie podría usarse para lanzar un ataque de reparación de sesión . En este ataque, la cookie establece su ID de sesión propia (ha iniciado sesión en otro lugar y ha olido la cookie). Cuando inicie sesión, si el sitio web no restablece la cookie, los dos compartirán una sesión de manera efectiva, lo que significa que posiblemente podrá ver sus datos o ejecutar transacciones en su nombre.