Vulnerabilidad Session Token en URL

# Exposición del Token de Sesión en la URL

¿Qué es esta vulnerabilidad?

Cuando entrás a un sitio y te logueás, el servidor te entrega un token de sesión: una cadena única que funciona como tu "pulsera de acceso". Mientras la tengas, el servidor sabe que sos vos y no te vuelve a pedir usuario y contraseña en cada clic.

El problema aparece cuando ese token viaja dentro de la URL, en lugar de ir en una cookie o en una cabecera segura. Por ejemplo:

$ https://mi-app.com/dashboard?session_id=8f3a9c2b7e1d4056a1b2c3d4e5f6a7b8

Ese session_id es la llave de tu cuenta viajando a la vista de todos. Y una URL, a diferencia de una cookie, se guarda, se comparte y se registra en muchísimos lugares por los que no tenés control.

Formalmente esto se clasifica como CWE-598 (uso de GET con datos sensibles en la query string) y aparece en las guías de OWASP bajo "Session ID in URL Rewrite".

¿Por qué es peligrosa? El punto es dónde termina esa URL

Una URL no es un dato efímero. Deja rastro en un montón de sitios, y en cada uno de ellos el token queda expuesto:

Historial del navegador. Cualquiera que use la misma computadora (una PC compartida, un locutorio, la de la oficina) puede abrir el historial y ver la URL completa, token incluido.

Logs del servidor. Los servidores web registran cada URL solicitada por defecto. Eso significa que tu token de sesión queda escrito en texto plano en archivos de log a los que acceden administradores, sistemas de monitoreo y, si esos logs se filtran, cualquier atacante.

La cabecera Referer. Esta es la más traicionera. Cuando desde una página hacés clic en un enlace hacia otro sitio, tu navegador manda la URL de origen en la cabecera Referer. Si tu URL tenía el token, se lo estás regalando a un tercero: a Google Analytics, a una CDN, a un anuncio, a cualquier recurso externo que cargue esa página.

Enlaces compartidos. La gente comparte URLs sin pensarlo: copian y pegan en un chat, en un mail, en un ticket de soporte. Si el token va en la URL, están compartiendo el acceso a su cuenta sin darse cuenta.

Proxies, cachés e intermediarios. Proxies corporativos, cachés de CDN y otros intermediarios pueden almacenar o registrar la URL completa.

Shoulder surfing. Algo tan simple como que alguien mire tu pantalla y vea la barra de direcciones.

El resultado de cualquiera de estos caminos es el mismo: un atacante que consigue el token puede secuestrar tu sesión (session hijacking). Se pega el token, y para el servidor pasa a ser vos, sin necesitar tu contraseña.

Un ejemplo concreto

Imaginá una app de banca que, tras el login, te redirige a:

$ https://banco.com/cuenta?token=abc123xyz

Vos, dentro de esa página, hacés clic en un enlace a un artículo externo de un diario. Tu navegador manda al diario la cabecera:

$ Referer: https://banco.com/cuenta?token=abc123xyz

El servidor del diario registra ese Referer en sus logs. Ahora tu token de sesión bancaria está guardado en la infraestructura de un tercero con el que nunca acordaste nada. Si alguien accede a esos logs mientras tu sesión sigue viva, entra a tu cuenta.

Cómo detectarla

Es de las vulnerabilidades más fáciles de identificar:

Revisá las URLs de la aplicación después del login. Si ves parámetros como session_id, sid, token, auth, jsessionid, PHPSESSID u similares en la query string, ahí está.
Mirá los redirects: a veces la app usa cookies pero se le escapa el token en alguna redirección puntual.
Inspeccioná el tráfico con las herramientas de desarrollador del navegador o con un proxy como Burp Suite / OWASP ZAP.
Revisá los logs del servidor: si encontrás tokens de sesión ahí, ya estás filtrando.

Ilustración del procedimiento 🔍 click para ampliar

# Ejemplo Práctico

Para ilustrar la explicación teórica, desarrolle una aplicación web de ejemplo que contiene la vulnerabilidad mencionada.

Si lográn apreciar, en la captura se observa que luego de la autenticación, el servidor generá un token de sesión que viaja en la URL.

Cualquier persona que obtenga este token de autenticación podrá interactuar con la aplicación haciéndose pasar por el usuario legítimo.

Me paso en un pentest que realicé para un cliente que el token de sesión se enviaba en una cabecera HTTP denominada X-Token-X. Como prueba de concepto, copié el valor de dicho token y lo añadí como parámetro ?token= en la URL de una petición a la API. La aplicación aceptó el token independientemente de que se enviara por cabecera o por la URL, permitiéndome acceder a la cuenta del usuario autenticado. Lo que demuestra que la aplicación no restringe el origen desde el que acepta el token de sesión.

Si eliminamos el header X-Token-X nos tirá un error de NO AUTORIZADO, lo normal.

Pero si modificamos la request y le pasamos el valor del header X-Token-X en el parámetro ?token, observamos que la aplicación sigue validando la sesión a través de la URL y sigue siendo posible operando bajo la cuenta del usuario legítimo.

Como pueden ver, se trata de una vulnerabilidad relativamente sencilla, pero es un error que muchos desarrolladores cometen al implementar o gestionar los mecanismos de autenticación en aplicaciones y APIs. Una configuración inadecuada en el manejo de los tokens de sesión puede exponer información sensible y facilitar el secuestro de sesiones por parte de un atacante. La gravedad de esta vulnerabilidad dependerá de lo que el usuario pueda hacer dentro de la aplicación. En algunos casos, el impacto puede ser bajo si la cuenta solo permite acceder a información de poca relevancia. Sin embargo, en otros escenarios, el mismo token podría dar acceso a funcionalidades críticas, como descargar archivos con información confidencial, modificar datos, realizar operaciones importantes o incluso comprometer por completo la cuenta del usuario.

# REMEDIACIÓN

La solución de fondo es simple: el token de sesión nunca debe ir en la URL. Debe viajar en una cookie configurada correctamente.

Usá cookies con los flags correctos:

HttpOnly: impide que JavaScript lea la cookie, lo que corta muchos ataques de XSS.
Secure: la cookie solo se envía por HTTPS, nunca en texto plano.
SameSite=Strict (o Lax): limita que la cookie se mande en peticiones que vienen desde otros sitios, mitigando CSRF y fugas. Eliminá la reescritura de sesión por URL. Muchos frameworks tienen una opción de URL rewriting para mantener la sesión cuando el navegador no acepta cookies. Desactivala:
En PHP: session.use_only_cookies = 1 y session.use_trans_sid = 0.
En aplicaciones Java: configurá tracking-mode en COOKIE en el web.xml.
En general, revisá que tu framework no esté agregando el ID de sesión a los enlaces. Reforzá con buenas prácticas de sesión:
Regenerá el token después del login (previene session fixation).
Poné tiempos de expiración razonables y cerrá sesiones inactivas.
Invalidá el token del lado del servidor al hacer logout, no solo del lado del cliente.
Controlá la cabecera Referrer-Policy (por ejemplo no-referrer o strict-origin) como capa extra de defensa.

Advertencia: Todo el contenido de este artículo es estrictamente educativo. No nos hacemos responsables del mal uso de esta herramienta o información. Practica únicamente en entornos controlados y con autorización.