¿Cómo puede una aplicación web proteger a los usuarios cuando el navegador no es compatible con HSTS?

No puedes.

Lo mejor que puedes hacer es usar SSL en todo el sitio. Haga que todas las conexiones HTTP redirijan inmediatamente al usuario a HTTPS (redirigir a la página principal a través de HTTPS, por ejemplo, http://www.example.com/anything.html debería redirigir a https://www.example.com/ ). No publique ningún contenido a través de HTTP (que no sea un redireccionamiento inmediato a su página principal, a través de HTTPS). Establezca el indicador secure en todas las cookies (obviamente).

Esto no va a detener un ataque de intermediario que reduce la calificación del usuario a HTTP. Sin HSTS, no puedes evitar ese tipo de ataque.

No puedes hacer nada mejor que eso. Oh bien. Así es como va con IE.

Consulte también ¿Opciones al defenderse contra SSLstrip? .

Obviamente, no hay forma de prevenir un ataque que sucedería antes de que el tráfico llegue a su servidor. Simplemente no estás en posición de tener ningún efecto en ese momento.

Sin embargo, una cosa que puede hacer para evitar que nunca se envíe el tráfico no SSL es romper intencionalmente los enlaces no SSL. Como el webmaster normalmente probará sus enlaces al menos una vez antes de que se publiquen, esto les indicará que necesitan cambiar su protocolo a https.

Una forma sencilla de hacer esto es mostrar una página que advierte al usuario de que llegó a través de un enlace inseguro y le indica que "actualice sus marcadores", etc., y luego proporcione un enlace https para continuar donde quería. ir. Es bastante discreto y no obstaculiza a los usuarios normales , pero de todos modos da la pista a los diseñadores web que son el objetivo de este tipo de campaña.

Probablemente quieras darle a esta página un código de estado 404 para que no se interprete como contenido real. El inconveniente es que los motores de búsqueda confían en un redireccionamiento 302 para actualizar su índice para que apunte a la página correcta. Devolver un 404 eliminará el enlace del índice en lugar de actualizarlo a https. Por lo tanto, es posible que desee enviar bots 302 y enviar navegadores a su página "Actualice sus enlaces" 404.

HSTS es la única protección contra SSLStrip, sin embargo, puede tomar las siguientes precauciones para ayudar a prevenir ataques:

1. Asegúrese de que su aplicación web esté libre de Vulnerabilidades de contenido mixto . Esto realmente va más allá de HSTS porque no protege contra la extracción de JavaScript sobre HTTP de otros dominios.

2. Una solución común a los problemas de seguridad es EDUCACIÓN . Proporcione un mensaje discreto a los usuarios de que están usando un navegador inseguro y que deberían considerar usar Chrome o Firefox.

3. Establezca el indicador "seguro" en las cookies http (pero todos deberían estar haciendo esto de todos modos y no detiene el SSLStrip).

4. Introduzca JavaScript en cada página que detecta si la página se ha cargado a través de HTTP (lo que debería ser imposible debido a HSTS), e impida que el usuario use su aplicación web. Muestra una gran ventana ROJA que dice ESTÁS BAJO ATAQUE . Esto podría eliminarse con un ataque MITM dirigido, pero no si el atacante está usando SSLStrip a ciegas.

Lo primero que viene a la mente es configurar el servidor para que solo acepte conexiones SSL en las páginas relevantes y no permita conexiones HTTP. Esto debería impedir que el servidor envíe algo sensible al usuario, pero finalmente no va a detener un MITM activo que puede hacer una conexión insegura al usuario pero luego convertirlo en una conexión SSL del atacante al servidor. .

En última instancia, no estoy seguro de que se pueda hacer mucho más que eso, ya que sin un mecanismo para informar al cliente que no deben enviar las cosas de forma clara, van a aceptar lo que sean. contado.

Esto trae otro punto, no sé mucho sobre HSTS pero parece que un atacante activo que puede evitar la comunicación directa entre el host y el cliente también podría eliminar el HSTS, ya que HTTPS normalmente no se usa con un certificado de cliente. Para empezar, el usuario no vería una conexión segura, pero si no estamos confiando en que el usuario sepa qué debería o no debería ser HTTPS, entonces, en realidad, probablemente no sea un esfuerzo para nada que podamos agregar. comprobando que HTTPS también sea eliminado.

Supongo que otra idea sería poner algún tipo de llamada de JavaScript que verifique el tipo de conexión y muestre una advertencia, pero nuevamente, esto podría ser eliminado por un atacante activo. enlace