¿Se pueden manejar las sesiones de forma segura con las cookies deshabilitadas?

Question

¿Se pueden manejar las sesiones de forma segura con las cookies deshabilitadas?

#1 de Rоry McCune (2 votos)
#2 de SilverlightFox (0 votos)

2

He estado leyendo un poco aquí sobre el manejo de ID de sesión, y he aprendido que generalmente es una mala idea incluir un ID de sesión en el código fuente HTML y / o en la cadena de consulta. Por ejemplo, ¿Es correcto usar el formulario? campo (oculto) para almacenar el token de sesión y ¿Por qué pasar el ID de sesión como un parámetro url inseguro?

Teniendo eso en cuenta, ¿existe una forma segura de gestionar las sesiones si las cookies están deshabilitadas?

Como ejemplo, noté que el carrito de la compra de mi empresa coloca los ID de sesión en un campo de formulario oculto (para la acción de agregar al carrito), y si las cookies están deshabilitadas, también se adjuntan a las cadenas de consulta para todos los enlaces. Revisé una página de Google en caché y estoy seguro de que Google había guardado su propia ID de sesión. Luego tomé el ID de la sesión y visité el carrito de compras de Google; ya había caducado. Aún así, obviamente no soy un fanático de que esto sea posible en primer lugar.

En una nota relacionada, cuando pegué el primer enlace anterior, originalmente incluía? newreg = XXXXXXX (parecía un ID de sesión de algún tipo). Acababa de registrarme en security.stackexchange.com y volví a esa URL. Tal vez no sea un problema, pero pensé que era un buen ejemplo coincidente de cómo los identificadores de sesión se pueden compartir accidentalmente.

cookies session-management session-fixation

pregunta Mike Willis 30.01.2014 - 19:16

fuente

2 respuestas

Lea otras preguntas en las etiquetas cookies session-management session-fixation

El sitio web no siempre me desconecta. ¿Preocupación por la privacidad o estoy exagerando? Hash ID de usuario de forma segura

score 2 · Answer 1

Diría que depende de tu caso de uso. Si observa una solicitud HTTP POST, existen básicamente tres áreas donde se pueden colocar los datos, los encabezados, la URL y el cuerpo de la solicitud.

Si descartamos poner el token en el cuerpo de la solicitud o en la URL, eso nos deja con los encabezados de solicitud como un lugar para colocar el token de autenticación.

Existen esquemas que hacen uso de esto, por ejemplo, HTTP Basic Auth, Digest Auth y NTLM Auth.

Sin embargo, cada uno de ellos tiene desventajas y si son apropiados / seguros para su aplicación dependerá de la aplicación, el modelo de amenaza y la población de usuarios.

Si, por ejemplo, estamos hablando de una aplicación corporativa interna donde todas las máquinas cliente ejecutan variantes de Windows, la autenticación NTLM probablemente sea una buena idea.

Sin embargo, si está buscando una configuración general de comercio electrónico con una variedad de sistemas operativos para usuarios finales, no lo sería.

score 0 · Answer 2

Hay una forma segura en la que ha tratado: Colocar los ID de sesión en campos de formulario ocultos. Sin embargo, deben enviarse por POST (es decir, en el cuerpo de la solicitud).

La desventaja de este enfoque es que cada acción de navegación es necesaria para enviar un formulario.

Por ejemplo, podríamos tener un formulario para manejar la navegación en cada página construida así:

<form method="post" action="/navigate">

    <input type="hidden" name="navigationPage" />
    <input type="hidden" name="sessionId" value="12345678" />

</form>

Al hacer clic en la navegación, JavaScript se ejecutará y establecerá navigationPage en el valor apropiado (por ejemplo, myAccount , orderHistory , etc.) y luego enviará el formulario. El /navigate URI verificará el sessionId y luego navegará a la página especificada en navigationPage si la sesión es válida. Usando este método, todas las páginas dentro de su sesión iniciada tendrán el mismo URI ( www.example.com/navigate en este caso).

Esto es seguro porque la ID de la sesión no se perderá en los encabezados referer en el caso de los enlaces externos. Los enlaces externos pueden simplemente vincularse directamente al recurso y no serán la forma POST que utiliza la navegación interna.

Muchos sistemas bancarios emplean una técnica similar para una protección adicional contra el secuestro de sesiones dentro de la sesión. En estos escenarios, sessionId en el campo de formulario oculto se regenerará en cada carga de página, lo que garantiza que solo un navegador web navegue a la vez. Sin embargo, esto evitará el uso del botón Atrás porque obliga a volver a enviar los datos de la POST, o a abrir enlaces en pestañas separadas del navegador porque la ID no está actualizada en ambos lugares. Esto se usa a menudo en combinación con las cookies de sesión, pero se puede usar de forma aislada. Las acciones que requieren información adicional, como transferencias de dinero, pueden incluir simplemente campos de formulario adicionales que se enviarán con el formulario principal.

Otra ventaja de este enfoque es que es inherentemente seguro contra CSRF . Si otra página realiza una solicitud entre sitios, faltará el sessionId porque no se enviará automáticamente de la misma forma que las cookies.