security - secure - http only site



Persistencia de sesión SSL y cookies seguras (2)

Actualmente tengo un servicio de seguridad de aplicaciones que se ejecuta en su empresa y se encuentra, en su mayor parte, satisfaciendo 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 estaban en el pasado 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 IP de origen. 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).

Hasta ahora, mi investigación ha revelado esto , 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, sin embargo, me queda la sospecha persistente 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 en cualquier momento -de manera efectiva y arbitraria- optar por renegociar la sesión SSL y, por lo tanto, cambiar la clave.

este es el escenario que estoy imaginando:

  1. Sesión SSL establecida y 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. Ocurre algo que causa 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 clave de sesión anterior (dado que no había conocimiento de nivel de aplicación de la renegociación, no hubo oportunidad de escribir un nuevo hash actualizado en el cliente).
  6. El servidor rechaza la credencial del cliente debido a una falla de coincidencia de hash, etc.

¿Es esto un problema real o es un malentendido de mi parte debido a una comprensión (por decir lo menos) menos que perfecta 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

Me pregunto por qué no sería suficiente simplemente

  1. requiere ssl en su transporte
  2. codificar las entradas (html / url / attribute) para evitar secuencias de comandos entre sitios
  3. solo requieren POST para todas las solicitudes que cambian la información y
  4. evite CSRF lo mejor que pueda (dependiendo de lo que admita su plataforma).
  5. Configure sus cookies en HTTPOnly




https