2010-05-15 11 views
8

En el desarrollo web, cuando se habilita el estado de la sesión, se almacena una identificación de sesión en la cookie (en el modo sin cookies, se utilizará la cadena de consulta en su lugar). En asp.net, la identificación de la sesión se cifra automáticamente. Hay muchos temas en Internet sobre cómo debe encriptar su cookie, incluida la identificación de la sesión. Puedo entender por qué quieres encriptar información privada como DOB, pero cualquier información privada no debe almacenarse en una cookie en primer lugar. Entonces, para otros valores de cookies, como la identificación de sesión, ¿cuál es el cifrado de propósito? ¿Agrega seguridad? no importa cómo lo asegure, será enviado de vuelta al servidor para su descifrado.¿El cifrado de la id de sesión (u otro valor de autentificación) en la cookie es útil?

Sé ser más específicos,

con fines de autenticación,

  1. desvío sesión, i no quieren hacer frente a tiempo de la sesión fuera más
  2. tienda de algún tipo de valor de id en la cookie,
  3. en el lado del servidor, compruebe si el valor de identificación existe y coincide, si lo es, con la autenticación del usuario.
  4. Deje que el valor de la cookie caduque cuando la sesión del navegador finalice, de esta manera.

vs

Asp.net mecanismo de autenticación forma (que depende de la sesión o del ID de sesión, creo)

hace este último una oferta mejor seguridad?

+2

¿Qué quiere decir con encriptación? – Gumbo

+0

Me refiero a algún tipo de método symMetric como AES o TDES – JiJ

Respuesta

22

Los ataques a sesiones como el Secuestro de sesión tienen como objetivo una ID de sesión válida. Si ahora encriptaste la ID de la sesión, los atacantes simplemente apuntarían a la ID de la sesión cifrada y no tendrías ninguna ventaja. Entonces, encriptar la ID de la sesión es inútil. Recuerde que la ID de la sesión es solo un valor aleatorio que se usa para identificar una sesión. Los atacantes no necesitan saber si ese valor aleatorio tiene algún significado específico; solo necesitan saber ese valor aleatorio.

Si desea asegurar su sesión, utilice HTTPS para cifrar toda la comunicación HTTP a través de SSL y configurar las cookies únicamente con las banderas

  • seguro que sólo permiten la cookie para ser enviada a través de HTTPS y
  • HttpOnly para prohibir el acceso local a través de JavaScript.
+0

+1 ¡Maldita sea Gumbo! Iba a decir https y HttpOnly cookies. – rook

+0

Gracias. https Hace que la comunicación sea segura, lo cual sé. Pero la cookie httponly es muy interesante, investigará. – JiJ

+1

En realidad, depende. Si el número aleatorio no fue criptográficamente seguro, cifrarlo con una clave del lado del servidor generará una mayor seguridad. Si utilicé números de sesión secuenciales, es trivial adivinar una sesión válida. Si cifro eso para que se vuelva criptográficamente seguro, puede saber que 2 es el siguiente número de sesión, pero no tiene idea de qué valor necesita proporcionar para obtener la sesión 2. Si el número aleatorio era criptográficamente seguro para empezar, entonces no importa sin embargo. –

4

Creo que lo que se refiere al "siempre debe encriptar sus datos" es usar SSL en sus conexiones usando un certificado debidamente firmado. Esto encriptará toda la comunicación entre el cliente y el servidor.

No veo ningún otro uso en el cifrado adicional de la ID de sesión (que en primer lugar es una identificación generada aleatoriamente).

-3

Encriptar cosas al azar no te llevará a ninguna parte ...

+0

¿Qué tipo de respuesta es esa? ¡Terrible! – TheCarver

1

Esto está documentado en el OWASP site

Via web.config en el elemento system.web/httpCookies

<httpCookies httpOnlyCookies="true" …> 

o mediante programación

C# Code: 
HttpCookie myCookie = new HttpCookie("myCookie"); 
myCookie.HttpOnly = true; 
Response.AppendCookie(myCookie); 
1

Los datos enviados a través de SSL (HTTPS) está totalmente encriptada, encabezados incluido (por lo tanto, cookies), solo el host al que está enviando la solicitud no está encriptado. También significa que la solicitud GET está encriptada (el resto de la URL). Aunque un atacante podría obligar a un cliente a responder a través de HTTP, por lo que es muy recomendable utilizar el indicador "Seguro" en su cookie, que impone el uso de HTTPS para enviar cookies.

El atributo de seguridad no tiene valores asociados. Por el contrario, la presencia de los nombres de los atributos indica que se ha especificado el comportamiento de seguridad. El atributo Secure está destinado a mantener la comunicación de cookies limitada a la transmisión cifrada, ordenando a los navegadores que usen cookies solo a través de conexiones seguras/encriptadas. Naturalmente, los servidores web deben establecer cookies seguras a través de conexiones seguras/cifradas, para que la información de las cookies no se transmita de manera que permita escuchar a escondidas cuando se envía por primera vez al navegador web.

Cuestiones relacionadas