¿Cuál es la diferencia entre usar HSTS y hacer una redirección 301?

Veamos el escenario con un redireccionamiento 301 primero. La víctima envía una solicitud a http://example.com (como se señaló en los comentarios, esto podría deberse a SSLStrip o porque el usuario acaba de ingresar example.com en la barra de URL y los navegadores están predeterminados en HTTP). Si no hay un ataque MitM, obtienen una respuesta 301, y se redirige a https://example.com . Pero si hay un MitM, el atacante puede optar por no enviar el 301, pero en cambio, ofrecer una copia (posiblemente modificada) del sitio a través de HTTP.

El punto débil aquí es que se realiza una conexión HTTP inicial (sin TLS), y el atacante puede modificar ese tráfico. Sin embargo, si hubiera utilizado HSTS, el navegador sabría (suponiendo que la víctima había visitado el sitio anteriormente) que la página siempre debería mostrarse a través de HTTPS: no se habría enviado ninguna solicitud HTTP y el navegador simplemente enviaría una solicitud a %código%. El atacante no puede mitigar la conexión TLS, por lo que se evita el ataque.

(El hecho de que los navegadores almacenen en caché las respuestas 301 hace que esto sea un poco más complicado en la práctica. Para obtener más información al respecto, consulte bonsaiviking's gran respuesta o esta pregunta . El cuento es que el 301 que se almacena en la memoria caché puede ayudar un poco, pero no te llevará a todo lo que HSTS hace.)

La seguridad de transporte estricta de HTTP (HSTS) está diseñada para la seguridad. HTTP 301 Movido de forma permanente se utiliza para la redirección de URL.

La redirección 301 es una parte importante de la implementación de un sitio web HTTPS. Como parte del protocolo HTTP, es compatible con más navegadores que HSTS. Sirve como el principal medio para actualizar una conexión de texto plano a HTTPS, actualizar los índices de búsqueda y evitar la rotura de enlaces.

En muchos casos, estos dos métodos tienen la misma debilidad: la solicitud inicial cuando el usuario escribe "example.com" en su navegador recibe un texto simple. Si esa solicitud inicial se realiza en una red hostil con una persona activa en el medio (MITM), la respuesta puede ser interceptada y la conexión no se actualizará a una segura.

Sin embargo, hay muchas razones por las que HSTS es importante y una gran mejora de la seguridad con respecto a una redirección 301 estándar:

• HSTS cubre todo el dominio. Un redireccionamiento 301 solo cubre una ruta URI específica. Si se redirige a un usuario para example.com/ , entonces una solicitud posterior a example.com/somepage seguirá utilizando HTTP inicialmente, y debe volver a redirigirse. Un sitio que utiliza HSTS solo requiere una solicitud para cubrir todo el sitio.
• HSTS funciona incluso con una conexión HTTPS inicial. Un redireccionamiento 301 solo asigna un URI de texto sin formato a uno HTTPS, por lo que visitar el HTTPS uno no confiere protección a las visitas posteriores.
• HSTS usa un caché separado con un tiempo de espera diferente. La memoria caché 301 a menudo está vinculada a la memoria caché de solicitud del navegador, que está diseñada para el rendimiento. Si no visita una página durante un tiempo, probablemente se borrará de la memoria caché para favorecer los sitios visitados con más frecuencia. Incluso puede haber una edad máxima para este caché que es de unas pocas semanas o meses. Una solución común para "el sitio no funciona" es decirle al usuario "borrar su caché". Todo esto volvería a exponer al usuario a la amenaza MITM. Los tiempos de espera de HSTS suelen ser del orden de meses a años, y el caché suele estar separado, por lo que no puede borrarse fácil o accidentalmente.
• HSTS puede ser precargado en un navegador por el fabricante. Google hace esto con su navegador Chrome basado en los encabezados descubiertos durante el rastreo web y enviados directamente a su programa. Para los sitios precargados, el navegador nunca tendrá que visitar a través de texto plano en primer lugar; siempre se puede asumir que es solo para HTTPS.

En primer lugar, algunos navegadores antiguos no admiten HSTS, por lo que aún necesita redirigir HTTP a HTTPS, establecer el indicador secure en todas las cookies, etc. Ahora, dicho esto ...

Además de las buenas razones enumeradas anteriormente (aunque la respuesta de @anders realmente debería haber mencionado SSLStrip , desde que derroté eso El ataque exacto es uno de los propósitos principales de HSTS), hay otro ataque que HSTS protege contra las redirecciones simples, pero no lo hace.

Digamos que se está visitando un sitio completamente en HTTPS. El usuario es realmente cuidadoso y solo solicita este sitio a través de HTTPS. No se necesita redireccionar. No hay HSTS, pero tampoco hay enlaces al sitio a través de HTTP no seguro, por lo que todo el tráfico del sitio está cifrado.

Sin embargo, supongamos que el sitio tiene una vulnerabilidad de seguridad en la que refleja una cookie específica (si está presente) en la página sin un escape adecuado (XSS basado en cookies, raro pero difícilmente desconocido). El atacante no puede realmente leer (y mucho menos modificar) el tráfico HTTPS, pero realmente desea acceder a la sesión del usuario en ese sitio HTTPS. Por lo tanto, esperan que el usuario visite algún otro sitio otro a través de HTTP, y modifican la respuesta de ese sitio para incluir una solicitud invisible (tal vez una fuente de script) a http://securesite.com/ (su sitio solo de HTTPS , pero sobre HTTP en su lugar). Lo que pasa después:

• Si el sitio tiene una política HSTS activa en el navegador, el navegador reescribe automáticamente la solicitud como https://securesite.com/ y el atacante no puede leer ni modificar ningún tráfico.
• Si el atacante no manipula pero el sitio no tiene HSTS, la solicitud se apaga, obtiene un 301 a https://securesite.com/ y la solicitud se apaga nuevamente a través de HTTPS.
  • Sin embargo, todas las cookies de securesite.com pero sin la marca secure se incluirán con esa solicitud inicial no segura. El atacante puede leerlos incluso a través de escuchas pasivas en ese punto. Eso es malo (y esta es una razón por la que las cookies confidenciales siempre deben tener el indicador secure , incluso si el sitio no debería nunca se puede acceder a través de una conexión insegura).
• Sin embargo, si todas las cookies son secure , eso hace que este ataque sea inútil. El atacante tendrá que manipular de nuevo. Pueden falsificar o modificar la respuesta a la solicitud insegura. En este caso particular, el atacante agregaría un encabezado Set-Cookie a la respuesta, colocando una cookie en el navegador del usuario que se enviará en futuras solicitudes a securesite.com, a través de HTTP o HTTPS.

Con el hipotético vector XSS basado en cookies (o cualquier otra cosa en la que un ataque de plantación de cookies pueda hacer daño), el atacante ha atacado con éxito un sitio en el que el usuario tuvo mucho cuidado de acceder solo a través de HTTPS , solo porque no estaba usando HSTS y tenía una vulnerabilidad que sería imposible de explotar sin una conexión no segura.

La clave a tener en cuenta es que la La misma política de origen para las cookies es más laxa que la Política del mismo origen en otros lugares. Es decir, no hay un solo canal seguro para las cookies, son el mismo origen:

Client ----Plain HTTP----> Server
Client ---------HTTPS----> Server

Por supuesto, el indicador de seguridad se puede configurar para que un valor de cookie se pueda configurar para transferir solo a través de HTTPS.

por ejemplo

Set-Cookie: foo=bar; secure

Client --> HTTP  (no cookies)      --> Server
Client --> HTTPS (Cookie: foo=bar) --> Server

Sin embargo, no hay forma de que el servidor sepa si una cookie se configuró con el indicador de seguridad.

por ejemplo sobre HTTP simple

Set-Cookie: foo=bar

Client --> HTTPS (Cookie: foo=bar) --> Server

El servidor estará en esta situación:

Entonces,aunquelascookiesestablecidasporelservidoratravésdeHTTPSnosondetectables,unMITMpuedeinyectarsuspropiosvaloresenunasesión"segura". Esto es cierto incluso si no tiene un servicio HTTP simple:

Client ----Plain HTTP----> No service
Client ---------HTTPS----> Server

... porque un MITM aún puede generar una solicitud HTTP simple a su dominio e inyectar la cookie:

Client ----Plain HTTP----> MITM --> No service
Client ---------HTTPS-------------> Server

Esto puede provocar algunos ataques en caso de que su sitio tenga algunas vulnerabilidades que de otro modo no podrían explotarse:

• Fijación de sesión: ¿Cómo puede una cookie no segura o no solo de HTTP afectar la seguridad de un sitio web de HSTS?
• Intoxicación por cookies de XSS: Flash cookie and man- en el medio

Además de lo anterior, los ataques de estilo ssltrip se pueden llevar a cabo sin HSTS. sslstrip se basa en un grado en que el usuario no se da cuenta de que no hay HTTPS.

También vea esta respuesta .

HSTS usa un redireccionamiento del lado del cliente en el espacio aislado 307, por lo que ni siquiera llega al servidor hasta que está en modo https explícito. Por otro lado, un redireccionamiento 301 es del lado del servidor, requiere recursos, tiempo para completarlo, etc. Además, un 301 acumula su cuenta de redireccionamientos [encadenados], lo que generalmente se atribuye a la dilución SEO.

Por lo tanto, HSTS es generalmente la mejor opción debido a su lado del cliente + naturaleza de espacio aislado. Pero, existe un "peligro" con un TTL muy largo en la memoria caché. Cuando un SSL expire o si desea volver, los usuarios del modo http quedarán bloqueados. Esto se debe a que el HSTS TTL guardado en la caché solo busca https, pero los navegadores no tienen acceso a ningún sitio con un certificado caducado. Así que nunca deje que caduque o cambie de modo sin configurar el tiempo de caché HSTS a 0 en las semanas (o meses) antes del cambio :) No debe preocuparse por esto con 301, ya que no es el navegador el que toma la decisión de redirigir o no: las personas no se bloquearán si realiza el cambio de servidor.