Persistencia de sesión SSL y cookies seguras

Question

Actualmente tengo un servicio de seguridad de aplicaciones que se ejecuta en mi empresa y que, en su mayor parte, satisface las necesidades comerciales.

El problema al que me enfrento actualmente es que el servicio se ha basado tradicionalmente (ingenuamente) en que el IP de origen del usuario permanezca constante como protección contra el secuestro de sesión: las aplicaciones web de la empresa no están disponibles directamente para el público y era en el pasado, era perfectamente aceptable para mí requerir que la dirección de un usuario permanezca constante a lo largo de una sesión determinada.

Desafortunadamente, este ya no es el caso y, por lo tanto, me veo obligado a cambiar a una solución que no dependa de la fuente IP. Preferiría implementar una solución que realmente cumpla con la intención del diseñador original (es decir, evitar el secuestro de la sesión).

Mi investigación hasta ahora ha aparecido this, que básicamente dice "sal a tu hash de token de autenticación con la clave de sesión SSL".

A primera vista, parece una solución perfecta, pero me queda la sospecha de que la implementación de este esquema en el mundo real no es práctica debido a la posibilidad de que el cliente y el servidor puedan hacerlo en cualquier momento arbitrariamente: opte por renegociar la sesión SSL y, por lo tanto, cambie la clave.

Este es el escenario que estoy imaginando: Sesión de

1. SSL establecida y la clave acordada.
2. El cliente se autentica en el servidor a nivel de la aplicación (es decir, a través del nombre de usuario y la contraseña).
3. El servidor escribe una cookie segura que incluye la clave de sesión SSL.
4. Se produce algo que provoca una renegociación de la sesión. Por ejemplo, creo que IE hace esto en un temporizador con o sin un motivo.
5. El cliente envía una solicitud al servidor que contiene la antigua clave de sesión (dado que no había conocimiento de nivel de aplicación de la renegociación, no había oportunidad de escribir un nuevo hash actualizado en el cliente).
6. Server rechaza la credencial del cliente debido a desmenuzar el fracaso partido, etc.

Es éste un problema real o se trata de un malentendido por mi parte debido a una (por decir lo menos) a menos que perfecta comprensión de ¿Cómo funciona SSL?

Answer 1

Sí, pero hay varias cosas que puede hacer al respecto. Lo más fácil es simplemente almacenar en caché la (s) clave (s) de sesión que usa como sal (por usuario), y aceptar cualquiera de ellas. Incluso si la sesión se renegocia, aún la tendrá en su caché. Hay detalles - política de vencimiento, etc. - pero nada insuperable a menos que estés ejecutando algo que necesita ser reforzado, en cuyo caso no deberías hacerlo de esta manera en primer lugar.

- MarkusQ

Answer 2

ver todos los temas relacionados con SSL persistence. Este es un problema bien investigado en el mundo del equilibrador de carga.

La respuesta corta es: no puede confiar en el SSLID - la mayoría de los navegadores renegocian, y usted todavía tiene que usar el IP de origen.Si es probable que la dirección IP cambie a mitad de sesión, puede forzar una reautenticación suave o usar el SSLID como un puente entre los dos cambios de IP (y viceversa, es decir, solo asuma el secuestro si ambos dirección IP y SSLID) cambiar al mismo tiempo, como se ve por el servidor.)

2014 ACTUALIZACIÓN

Sólo forzar el uso de https y asegúrese de que que usted no es vulnerable a session fixation o para CRIME. No se moleste en saltear su token de autenticación con ninguna información del lado del cliente porque si un atacante pudo obtener el token (siempre que dicho token no fuera simplemente trivial de adivinar), entonces se usaron los medios para obtenerlo (por ejemplo, cross-site scripting, o compromiso total del sistema del cliente) también le permitirá al atacante obtener fácilmente cualquier información del lado del cliente que pueda haber ingresado en el token (y replicar aquellos en un sistema secundario si es necesario).

Si es probable que el cliente se conecte solo de unos pocos sistemas, puede generate an RSA keypair in the browser para cada nuevo sistema cliente al que se conecte el cliente (donde la parte pública se envía a su servidor y la parte privada permanece en lo que es con suerte seguro almacenamiento de cliente) y redirigir a un host virtual que usa two-way (peer/client certificate) verification en lugar de la autenticación basada en contraseña.

Answer 3

Me pregunto por qué no sería suficiente para simplemente

1. requerir SSL en su transporte
2. entradas codificar (html/url/atributo) para evitar cross-site scripting
3. sólo requieren POST para todas las solicitudes que cambian la información y
4. evitan CSRF lo mejor que pueden (dependiendo de lo que admita su plataforma).
5. Establecer sus cookies para HTTPOnly