almacenamiento de sesión en la cadena de consulta

Esto solía ser un uso común en la antigüedad cuando los clientes no confiaban en los sitios web ni en el navegador web por su seguridad y privacidad y rechazaban sistemáticamente los javascript y las cookies. Como HTTP no es un protocolo conectado, la sesión debe usar algunos datos para pasar la identificación de la sesión entre el cliente y el servidor. Eso significa que si no puedes usar cookies para las solicitudes GET, solo te queda un parámetro de URL. Eso se implementó en muchas aplicaciones web como sesión a través de la reescritura de URL .

Ahora rara vez se usa, porque navegar en la mayoría de los sitios mientras se deshabilitan las cookies es simplemente imposible. Así que los usuarios han sido educados para permitir constantemente las cookies en sus navegadores.

Desde un punto de vista de seguridad, pasar el ID de sesión en la URL no es peor que pasarlo en una cookie: si alguien (excepto el propio usuario) puede interceptar la URL, también puede interceptar la cookie. Y la fijación de la sesión no es más fácil con la URL que con las cookies: es el problema del servidor el que debe invalidar los identificadores de sesión antiguos y crear uno nuevo después de una autenticación exitosa. Los registros tampoco son un problema: un ID de sesión solo tiene sentido durante la duración de la sesión y no es una información confidencial a largo plazo. El único lugar que podría causar problemas es las solicitudes de redireccionamiento entre sitios. En ese caso, el encabezado REFERER podría contener el ID de sesión. Por lo tanto, una aplicación bien diseñada que utilice la reescritura de URL para sus sesiones, debe almacenar constantemente la IP del cliente en el lado del servidor de sesión y controlar que la ID de sesión y la IP del cliente coincidan.

TL / DR: ese uso se conoce como sesión a través de la reescritura de URL. Ahora se usa raramente porque la sesión a través de cookies es mucho más común. El problema no es la seguridad porque la seguridad de un parámetro de URL no es diferente de la de una cookie, pero ese parámetro adicional se muestra en la barra del navegador y puede intrigar a un usuario, o requerir la eliminación para almacenar una URL limpia como un marcador .

Entre su propia lista de problemas potenciales y el enlace de iain, no queda mucho por decir. El hecho de que la sesión haya funcionado en una ventana de incógnito significaría que las cookies no están involucradas en la autenticación. Esto deja una gran oportunidad para la fijación de la sesión. Si nada más, el tipo de fijación en la que el malo crea un vínculo con SU PROPIA ficha de sesión y engaña a la víctima para que la visite y guarde información confidencial.

Además, esto significaría que la aplicación está utilizando GET para todas sus transacciones de actualización o está utilizando POST con parámetros de URL. Ninguno de ellos se considera una gran práctica (consulte este enlace para más detalles). Lo más probable es que la aplicación esté violando la idempotencia del método.

Resumen de posibles efectos adversos:

• Registros de todo tipo potencialmente grabando tokens de sesión
• Infracción potencial del método HTTP idempotence
• Fijación de sesión

Jugando al abogado del diablo, me pareció que una tentación detrás de este diseño podría ser la protección CSRF. Sin las cookies involucradas y el tráfico protegido por SSL, esto podría tener un efecto similar al de la protección CSRF. El atacante no tiene el hash largo necesario para crear la URL correcta y no requiere cookies.

Mientras el sitio esté protegido mediante HTTPS, todas las consultas en la URL también se enviarán encriptadas, por lo que no debería haber nada que pudiera exponer la consulta entre su PC y el servidor. El único problema que se me ocurre aquí es que, accidentalmente, podría enviarlo a otras personas a través de copiar / pegar o compartir la pantalla.