¿Por qué Tornado no tiene sesión?

  

He escuchado que las cookies son menos seguras que la sesión.

Debes haber malinterpretado algo. De hecho, las sesiones HTTP generalmente se implementan utilizando cookies.

  

Estoy pensando que si pudiera obtener & ^ * Y () UIH | > Guho976879, todavía puedo falsificar la cookie, ¿no?

Seguro que puede cambiar la cookie, pero ¿será aceptado por el servidor como válido? Si toma un real, consulte la documentación que verá:

  

Las cookies no son seguras y los clientes pueden modificarlas fácilmente. Si necesita configurar cookies para, por ejemplo, identificar al usuario que ha iniciado sesión actualmente, necesita firmar sus cookies para evitar la falsificación . Tornado admite cookies firmadas con los métodos set_secure_cookie y get_secure_cookie. ...
  Las cookies firmadas contienen el valor codificado de la cookie además de   una marca de tiempo y una firma HMAC. Si la cookie es vieja o si   la firma no coincide, get_secure_cookie devolverá Ninguno como si   la cookie no está establecida .

Por lo tanto, si intenta manipular la cookie segura, el marco notará y tratará la cookie como no válida, es decir, como la cookie nunca se envió en primer lugar.

Creo que las otras respuestas no logran abordar el ataque primario contra el que se está protegiendo aquí, que no es falsificar la cookie, sino manipular , o inspeccionándolo .

Si envía una cookie a un navegador que dice "current_user = tom", el usuario puede enviarle una cookie alternativa que dice "current_user = dave". Si no tiene nada contra lo que validar la cookie, su aplicación asumirá que están registrados como "dave".

Esto podría mitigarse firmando la cookie usando una clave secreta: la cookie manipulada no tendría la firma correcta, por lo que se rechazaría.

Sin embargo, todavía puede haber un problema: si parte del estado que desea almacenar es secreto . Por ejemplo, es posible que desee almacenar el precio de costo y el marcado de los productos en la canasta del usuario; claramente una cookie de texto simple que el usuario puede leer no es apropiada aquí.

Esto te deja con dos soluciones:

• Encripte el contenido de la cookie, para que no pueda leerse ni modificarse sin conocer la clave privada.
• Almacene los datos reales localmente (por ejemplo, en un disco o en un almacén de memoria) y envíe solo un identificador en la cookie. Esto se conoce generalmente como "datos de sesión".

Las sesiones son relativamente fáciles de implementar y son probablemente seguras contra estos ataques en particular. Sin embargo, imponen cargas a su infraestructura de back-end, porque sus servidores web / de aplicaciones necesitan poder escribir y leer los datos; Esto puede ser complicado en configuraciones complejas de equilibrio de carga, por ejemplo. Como tal, el cifrado de una pequeña cantidad de datos directamente en la cookie puede ser una alternativa sensata, ya que ahora los únicos datos que deben compartirse entre los servidores de su aplicación son la clave privada.

Tenga en cuenta que ninguno de estos protege directamente contra otros ataques, como el secuestro, donde un usuario malintencionado simplemente clona las cookies de una sesión genuina. Los tokens de sesión también pueden ser vulnerables a un ataque relacionado llamado "fijación de sesión", donde un atacante elige el identificador antes de que un usuario genuino se conecte y, por lo tanto, puede crearles cookies idénticas; esto no sería posible con una cookie encriptada, pero estoy seguro de que hay otros ataques únicos a su vez.

La pregunta que has encontrado no describe realmente a qué (creo) te refieres. La diferencia que están describiendo es si la información de la sesión del usuario (por lo tanto, cosas como qué artículo está comprado en su compra, por ejemplo) del lado del servidor y solo pasa un identificador único (también conocido como cookie de sesión) al cliente, o si se almacena todo. en el cliente.

Todas las aplicaciones web deben tener algún mecanismo para mantener el estado. HTTP es sin estado por defecto, por lo que no hay forma de que un servidor corresponda una solicitud a otra.

La forma en que la mayoría de las aplicaciones resuelven esto es mediante el uso de cookies. Los desafíos de seguridad de usar cookies se comprenden bien y, si se implementan correctamente, no deberían causar problemas de seguridad importantes.

Las otras opciones para hacer esto son generalmente encabezados de autorización, por lo tanto, ya sea mediante el resumen HTTP o la autenticación NTLM. que es más común en las aplicaciones corporativas internas, o para generar esos encabezados usando JavaScript (que se ve con algunas aplicaciones modernas de una sola página).

Independientemente de lo necesario, debe haber alguna información que se pase del cliente al servidor con cada solicitud para identificar al usuario.

En cuanto a la creación de cookies, normalmente un token de sesión tendrá un alto grado de aleatoriedad, por lo que no es práctico falsificar un valor de cookie.