security - sent - httponly cookie php

Persistencia de sesión SSL y cookies seguras

Question

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

Answer 3

Ver todos los temas relacionados con la persistencia de SSL . 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 aún debe usar la IP de origen. Si es probable que la dirección IP cambie a mitad de la sesión, puede forzar una reautenticación suave o usar el SSLID como puente entre los dos cambios de IP (y viceversa, es decir, solo asuma el secuestro si cambian tanto la dirección IP como el SSLID en al mismo tiempo, como lo ve el servidor).

ACTUALIZACIÓN 2014

Simplemente fuerce el uso de https y asegúrese de que no sea vulnerable a la fijación de sesión o al CRIMEN . 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 , scripts entre sitios) , o el completo compromiso del sistema 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 generar un par de claves RSA en el navegador 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 él). qué es, con suerte, el almacenamiento seguro del cliente) y redirigir a un host virtual que utiliza la verificación bidireccional (certificado de pares / clientes) en lugar de la autenticación basada en contraseñas.