HTTPS y cookie encriptada para la sesión

2

Actualmente estoy desarrollando un sistema SSO con CAS. CAS utiliza un ticket de otorgamiento de tickets (TGT) que se puede ver como la sesión SSO. CAS por defecto cifrará el TGT. Y, de forma predeterminada, también tiene HTTPS entre los nodos.

Como HTTPS ya se ocupa del cifrado, no entiendo por qué necesito cifrar el valor de la cookie (TGT). Sí, todavía puedes leer el valor de la cookie y usarlo, supongo. Pero cuando ya has secuestrado la sesión, también puedes hacerlo con el TGT encriptado, ya que el cliente simplemente envía un TGT encriptado al servidor y no lo descifra antes.

Entonces, mi pregunta es: ¿Cuáles son las razones de un valor de cookie cifrado si ya tiene HTTPS entre todos los nodos? ¿Puedes mencionar posibles escenarios de ataque?

    
pregunta Goldi 21.10.2016 - 09:42
fuente

3 respuestas

1

Es correcto que, por lo general, al acceder al sitio web cifrado de ssl no necesita cifrar las cookies normalmente, pero se trata de que, incluso si alguien secuestró su conexión ssl, el TGT debería ser inutilizable para esa persona.

Como en los escenarios de SSO las cosas cambian mucho.

Proceso de autenticación / flujo de solicitudes

Durante el proceso de autenticación una vez que se verifique su identidad en KDC (centro de distribución de claves), el servidor de autenticación le envía dos mensajes.

One message is the TGT that contains:
    your name/ID,
    the TGS name/ID,
    timestamp,
    your network address 
    lifetime of the TGT 
    TGS Session Key,
    and is encrypted with the TGS Secret Key . 

The other message contains:
    the TGS name/ID,
    timestamp,
    lifetime (same as above), and
    TGS Session Key
    and is encrypted with your Client Secret Key.

TGS Session Key es la clave compartida que se usará entre usted y TGS.  en el siguiente paso

Su clave secreta de cliente se determina al solicitarle su contraseña, agregar un salt y hashing todo. puede usarlo para descifrar el segundo mensaje para obtener la clave de sesión TGS. Sin embargo, no puede descifrar el TGT ya que no conoce la clave secreta de TGS. El TGT encriptado se almacena dentro de su caché de credenciales.

Ahora que tiene la clave de sesión TGS, puede solicitar el token final para acceder al servicio requerido desde TGS

El TGT (cifrado con clave secreta TGS) y para Ejemplo de solicitud de servicio HTTP (cifrado con clave de sesión TGS) se envía al TGS

TGS ahora descifra el TGT y recupera la clave de sesión TGS, con esta clave descifra la solicitud de autenticación http

El Servidor de concesión de tickets luego genera aleatoriamente la clave de sesión del servicio HTTP y prepara el ticket del servicio HTTP que contiene:

your name/ID,
HTTP Service name/ID,
your network address 
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
and encrypts it with the HTTP Service Secret Key.

Entonces el TGS te envía dos mensajes. Uno es el ticket de servicio HTTP cifrado; el otro contiene:

HTTP Service name/ID,
timestamp,
lifetime of the validity of the ticket, and
HTTP Service Session Key,
that is encrypted with the TGS Session Key.

hasta que reciba el mensaje, el cliente descifra el segundo mensaje y obtiene la clave de sesión http

Ahora el usuario tiene acceso al servicio HTTP

¿Qué pasa si TGT no estaba cifrado

Si TGT no estaba encriptado, cualquier persona que tenga eso puede alterar la solicitud del servicio HTTP, ya sea mediante la falsificación de la identidad de alguien en la solicitud y obtener la clave de sesión del servicio HTTP

Incluso un usuario puede explotar el proceso de autenticación jst al modificar el TGT

para evitar el uso indebido del cifrado TGT

    
respondido por el 8zero2.ops 21.10.2016 - 15:24
fuente
0

Las cookies permanecen en el navegador. Y si tienen información confidencial almacenada, deben estar encriptados. Aunque argumentaré que cualquier información confidencial no debe almacenarse en las cookies.
Y el cifrado de la ID de sesión (que ya es un valor aleatorio) no tiene ningún sentido. Y si está utilizando cierta información de usuario como ID de sesión, entonces esta práctica es mala en sí misma y, en lugar de cifrarla, debería pensar en redefinir cómo se gestiona una sesión. Compruebe OWASP para esto.

    
respondido por el one 21.10.2016 - 09:53
fuente
0

Si su cookie es solo una ID de sesión que le permite al servidor identificarlo, el cifrado es, como usted comenta correctamente, inútil además del cifrado TLS. Sin embargo, puede haber aplicaciones que realmente necesiten almacenar información en una cookie que quieran mantener confidencial, incluso confidencial para los usuarios que inspeccionan sus propias cookies con herramientas de desarrollo en el navegador. Un ejemplo podría ser una información de sesión para un entorno distribuido donde los servidores no comparten una sola base de datos y la cookie contiene, por ejemplo, un identificador confidencial del servidor emisor que no quiere que el usuario vea porque podría querer falsificar eso (por supuesto, esto es pura especulación).

Siempre trataría de evitar tal diseño y buscaría algún estándar abierto como SAML, pero estoy bastante seguro de que hay aplicaciones que lo hacen así.

    
respondido por el kaidentity 21.10.2016 - 10:19
fuente

Lea otras preguntas en las etiquetas