Supongamos que un usuario está autenticado y que todo el proceso de autenticación de la cuenta se realizó bajo HTTPS seguro.
Al iniciar sesión correctamente, el usuario es redirigido a la página de inicio. Sin embargo, la página de inicio contiene enlaces dentro del sitio web que no tienen SSL habilitado - HTTP básico.
Por ejemplo:
¿Se trata de una vulnerabilidad de seguridad y, en caso afirmativo, qué gravedad? Si no, ¿por qué? ¿No son inseguras las cookies cuando se pasa de HTTPS a HTTP?
En cuanto a la seguridad / privacidad de la navegación, cada vez que está en http, su tráfico podría ser interceptado y manipulado por los servidores (y, a menudo, es, ver la discusión de la caché a continuación). Período. No puede estar seguro de si la página que ve a través de una conexión http es de hecho la página que el servidor web envió en respuesta a la solicitud de su cliente web.
En cuanto al secuestro de sesiones, la respuesta es un poco más complicada. La preocupación sería que escriba su nombre de usuario y contraseña a través de una conexión https, y el servidor luego establece una cookie en su navegador que lo identifica. El navegador enviará esa cookie de vuelta al servidor con cada solicitud posterior de páginas y, por lo tanto, el servidor sabrá que es usted quien solicita las páginas. La preocupación es que alguien en el camino estaba escuchando y copiando esa cookie. Luego podrían enviar solicitudes al mismo sitio web utilizando su cookie, y el sitio pensaría que era usted.
El encabezado de Set-Cookie tiene un indicador seguro ( vea aquí ) que se puede activar cuando la cookie es originalmente dado a su navegador. Si se establece este indicador, el cliente web no enviará la cookie al dominio de origen, excepto a través de una conexión https.
Es posible que un sitio tenga, por ejemplo, dos cookies de autenticación, una de las cuales está marcada como segura. De esa manera, cada vez que desee hacer algo realmente confidencial, debe tener la cookie segura y, por lo tanto, se le redirige a una página https.
En ese caso, los diseñadores del sitio tienen que tomar una decisión por página en cuanto a qué es "realmente sensible" y qué no lo es. El alcance para "oops" es enorme. Esta es una de las razones por las que se prefiere https todo el camino. Hay razones por las que esto no se realiza en todos los sitios:
(Probablemente el motivo principal): muchas redes (potencialmente su ISP) mantienen un servidor de caché que vigila el tráfico que sale de su red. Si ve que está intentando recuperar contenido (por ejemplo, todas las pequeñas imágenes e iconos en una página popular) que otras personas han recuperado recientemente, le dará una versión en caché. Hay todo tipo de soporte para esto: el sitio original tiene una forma de indicar qué se puede y no se puede almacenar en caché y durante cuánto tiempo. Todo esto es bueno para el ISP y el sitio original, ya que significa que ambos tienen menos ancho de banda que entra y sale de sus redes. Https rompe esto, ya que el proxy ahora no tiene idea de lo que le está pidiendo al sitio original.
(ya no es un problema) es la sobrecarga computacional para configurar una conexión segura a un sitio por primera vez. Este solía ser un problema para un servidor que acepta muchas conexiones https. Este problema ya ha desaparecido en gran medida: hay varios factores de protocolo atenuantes, así como hardware de aceleración y otros métodos que básicamente han solucionado este problema. Solo menciono esto en caso de que escuche que https pone una pesada carga computacional en el servidor: AFAIK que ya no es cierto.
Sí , sin embargo , este es un patrón común.
Por ejemplo, así es como funciona la autenticación de reddit y la de Instagram.
Francamente, lo único contra lo que se protege es enviar su contraseña a través de la red en texto sin formato. Pero el proceso expone su sesión y todos sus datos de navegación a través de HTTP, lo que significa que su sesión tiene la misma fuerza que HTTP.
Algunas otras conclusiones de esto.