Sugerencias para evitar el secuestro de cookies en una aplicación web

Necesitaría asegurar la transmisión de GUID (considere la posibilidad de que un servidor se haga pasar por otro servidor, o por un intermediario); Sospecho firmemente que esto evolucionará rápidamente hacia algo que necesita cifrado asimétrico y, finalmente, una versión reducida de HTTPS. Dado que el HTTPS completo ya está disponible, parece una duplicación de esfuerzos.

Por otro lado, el uso de un GUID (que actúa, cuando todo está dicho y hecho, como una clave compartida [temporal]) no se defenderá contra el compromiso del cliente (malware, análisis forense 'negro', posiblemente incluso ingeniería social Dependiendo de cómo esté diseñada la interfaz). Para esto, necesitaría un sistema de depósito de confianza de confianza local, una especie de tarjeta inteligente segura, de modo que no pueda leer y duplicar lo que realmente contiene, al mismo tiempo que puede demostrarlo a un tercero (el servidor) que los datos están allí .

Pero en ese momento, ¿realmente necesitaríamos cookies ? Tendríamos una tarjeta inteligente con nuestros datos de inicio de sesión de usuario de forma segura; entonces sería mucho más sencillo vincular la sesión no al navegador, sino al nombre de usuario . La función "Recordarme" se realizará si usted conecta la tarjeta inteligente.

Otra posibilidad más sencilla sería, como sugiere el usuario lesto, almacenar el secreto acordado de forma privada en un área protegida por contraseña, un "llavero", "cartera" o "billetera", al igual que las contraseñas. El usuario desbloquea el anillo de claves con una contraseña maestra, luego el navegador puede autenticarse.

Pero todo el esquema se puede implementar de una manera más directa al obligar a las cookies seguras a almacenarse en el área segura junto con las contraseñas en caché . Al recibir una cookie a través de una conexión segura, el navegador solicitará al usuario que desbloquee el área segura, encuentre una cookie con el mismo nombre para el mismo dominio ya existente y luego repita la solicitud, esta vez enviando la cookie esperada. Desde el punto de vista del usuario, ingresa a un sitio seguro con la opción "Recordarme" habilitada, aparece una ventana emergente del navegador solicitando la contraseña maestra, y lo siguiente que sabe es que está conectado.

Un atacante no tendría forma (weeeellll ...) de acceder al intercambio de HTTPS, y si tuviera que apoderarse de la computadora, encontraría cookies y contraseñas en un bloque cifrado AES-256 para el que carece de acceso maestro llave.

Lo que sugiere tiene diferentes implicaciones de seguridad y privacidad y no funcionaría en general, ya que no puede garantizar la autenticidad de los GUID mencionados:

1. Se puede capturar fácilmente, solo tiene que redirigir al usuario a cualquier servidor web al que tenga acceso.
2. No hay nada que impida que alguien escriba un navegador personalizado (o que modifique el código fuente de uno existente) para falsificar el GUID, por lo que sus puntos "que no debían modificarse (bajo ninguna circunstancia)" realmente no funcionarán.
3. Hay varias otras implicaciones de privacidad con esta solución, como poder rastrear a alguien de forma única (si no observa los puntos anteriores).

  

¿Esto no solucionaría el problema del secuestro de sesión / el secuestro de cookies, ya que una cookie de un navegador sería totalmente inútil para otro navegador?

No completamente. ¿Qué pasa si alguien secuestra tu cookie en la misma computadora? (Ordenador público). ¿Y quién envía el GUID? El navegador en sí, por lo que deja una gran vulnerabilidad, ya que también podría copiar el GUID. ¡Nunca confíes en la entrada del usuario!

Le sugiero que eche un vistazo a HttpOnly: enlace

Cambie "GUID" con una clave privada, generada en el primer lanzamiento del navegador / proporcionada por el usuario (o tal vez basada en el dominio), y una forma de firmar e identificar la respuesta del cliente.

Esto es exactamente cómo funciona la autenticación automática basada en shell seguro (SSH). Pero para hacer realidad que tiene que editar el navegador para usar una clave privada fija o basada en el dominio, agrega una página de inicio de sesión donde un inicio de sesión exitoso cargará la clave pública del cliente y tendrá que almacenarse, y modificará el servidor HTTPS para verificar la identidad del cliente frente a la almacenada.

Tenga en cuenta que esto es muy similar al HTTPS real, "solo" tiene que agregar una clave de cliente persistente y una clave del lado del servidor < - > búsqueda de sesión.

En realidad, esto se denomina "protocolo de enlace TLS autenticado por el cliente", pero el intercambio de claves mediante el inicio de sesión clásico está fuera de lo normal.

Entonces, su sesión estará protegida siempre que la clave privada esté protegida, pero debido a que muchos navegadores brindan una forma de almacenar la contraseña en ellos, eso no debe considerarse una gran preocupación