¿Por qué debe cifrarse el valor de la cookie?

Bueno, supongo que si la información es secreta podría ser proteger los datos "en reposo". Esto podría ser contra usuarios legítimos de la PC o contra personas que obtengan una copia de la PC.

Generalmente, las cookies deben estar protegidas contra el cambio (integridad), en lugar de ofrecer confidencialidad. Sin embargo, esto puede realizarse colocando un valor de MAC sobre la cookie en lugar de cifrarla.

A veces las personas están cifrando un valor mágico (cuna) en lugar de colocar un MAC, por lo que este podría ser el caso de realizar una criptografía DIY.

Para responder a su pregunta específicamente, el cifrado de datos aleatorios no tiene ningún valor a menos que esté utilizando ambos el cifrado y los datos no cifrados. Por ejemplo, uno podría almacenarse en la base de datos del servidor , mientras que el otro se sirve en la cookie . Sin embargo, un mejor enfoque es utilizar un hash de una sola vía en lugar de cifrado. Lo describiré a continuación.

Aquí hay algunas pautas para la administración segura de cookies de token de sesión:

Primero, asegúrese de que la cookie esté marcada como Secure y HttpOnly , y que tenga al menos 72 bits de entropía de un PSRNG criptográficamente seguro .

Luego, dado que la conexión es segura con HTTPS, la única forma de que la cookie sea robada es con un ataque del lado del servidor (SQLi, etc.) o un ataque del lado del cliente (es decir, un virus en la PC). En ambos casos es probable que ya sea un problema grave . Pero a veces con estos ataques, el atacante solo obtendrá una cantidad limitada de datos. El solo hecho de secuestrar un token de sesión podría ser un verdadero ahorro de tiempo para el atacante, incluso si otros ataques son posibles también. Por lo tanto, en algunos casos, un esquema de administración de cookies de token de sesión bien asegurado puede hacer una gran diferencia.

Si el token de sesión es robado del cliente , no hay mucho que puedas hacer . Me gusta bloquear cada sesión en una sola dirección IP, pero eso no es aceptable para los usuarios móviles.

Sin embargo, suponiendo que los tokens de sesión fueron robados del servidor (es decir, un ataque SQLi de solo lectura), puede ayudar a mitigar esto mediante el diseño. En la base de datos del servidor, solo almacena un hash SHA-2 del token. De esta manera, el atacante no puede volver a convertirlo en un valor de cookie utilizable. Obviamente, tales ataques siguen siendo problemas graves por otras razones, al menos usted se ha asegurado con éxito contra este tipo de secuestro de sesión.

En general, la aplicación debe estar protegida contra XSS y SQLi, por supuesto.

Depende de si la cookie contiene información importante que le permita al usuario obtener información a la que no debería tener acceso.

Supongamos que tenemos un sitio cuando, al iniciar sesión, se establece una cookie admin con un valor verdadero / falso que describe si el usuario es un administrador, y cuando accede a páginas restringidas, el valor de esta cookie determina si el usuario tiene acceso.

Al cifrar y autenticar (MAC) la cookie evitará que el usuario la manipule con éxito.

De forma similar, la mayoría de los marcos web permiten almacenar todos los datos de la sesión en una cookie, en ese caso, no desea que el usuario pueda modificar los datos, por lo que debe autenticarlos y, dado que la sesión puede contener datos, el usuario No debería poder verlo cifrado también.

Por otro lado, si las cookies solo se usan para cosas que pertenecen al usuario en primer lugar (cookie de sesión, etc.) o si solo las utiliza el lado del cliente, no tiene sentido cifrarlas o autenticarlas.