Hace poco seguí una discusión en la que una persona decía que pasar el ID de sesión como parámetro url es inseguro y que, en su lugar, deberían usarse cookies. La otra persona dijo lo contrario y argumentó que Paypal, por ejemplo, está pasando el ID de sesión como parámetro de URL por razones de seguridad.
¿Pasar el ID de sesión como parámetro url realmente inseguro? ¿Por qué las cookies son más seguras? ¿Qué posibilidades tiene un atacante para ambas opciones (cookies y parámetro de URL)?
¿Pasar el ID de sesión como parámetro url es realmente inseguro?
Si bien no es inherentemente inseguro, puede ser un problema a menos que el código esté muy bien diseñado.
Digamos que visito mi foro favorito. Me registra y agrega mi ID de sesión a la URL en cada solicitud. Encuentro un tema particularmente interesante, y copio & pega la URL en un mensaje instantáneo para mi amigo.
A menos que la aplicación haya tomado medidas para asegurarse de que haya alguna forma de validación en el ID de sesión, el amigo que hizo clic en ese enlace puede heredar mi sesión, y luego Ser capaz de hacer cualquier cosa que yo pueda hacer, como yo.
Al almacenar los identificadores de sesión en las cookies, elimina por completo el problema de intercambio de enlaces.
Hay una variación en este tema llamada fijación de sesión , que implica un intercambio intencional de un identificador de sesión para fines maliciosos. El artículo de Wikipedia vinculado profundiza sobre cómo funciona este ataque y en qué se diferencia del intercambio involuntario del identificador de sesión.
¿Por qué las cookies son más seguras?
Las cookies pueden ser más seguras aquí, porque no son algo que los usuarios normales puedan copiar & pegar, o incluso ver y modificar. Son un valor predeterminado mucho más seguro.
¿Qué posibilidades tiene un atacante para ambas opciones?
Ninguno de estos métodos está a salvo de los ataques del hombre en el medio sobre la comunicación sin cifrar. Los complementos del navegador, el software espía y otros desagradables del lado del cliente también pueden espiar ambos métodos para almacenar identificadores de sesión.
En ambos casos, la validación del lado del servidor de que el cliente que dice poseer un ID de sesión es la mejor práctica. De qué se compone esta validación está en debate. Tenga en cuenta que los usuarios detrás de los proxies corporativos pueden saltar entre direcciones IP entre solicitudes, por lo que el bloqueo de una sesión a una dirección IP puede alienar accidentalmente a las personas. El artículo de fijación de sesión menciona algunas otras alternativas útiles.
La mayoría de los sitios web almacenan el estado de inicio de sesión de su usuario en la sesión, y si un atacante tiene el ID de sesión, también tiene los privilegios del usuario que ha iniciado sesión. En otras palabras, las dos preocupaciones de mantener la sesión y la autenticación a menudo están acopladas.
Un problema es que es fácil hacer fijación de sesión . En este caso, un atacante enviaría al usuario una URL preparada con un ID de sesión conocido. Si el usuario hace clic en esta URL y hace un inicio de sesión, el atacante tendrá una sesión con privilegios. Sin embargo, si el sitio web requiere una cookie, una URL preparada en un correo electrónico no será suficiente.
Si un sitio utiliza HTTP mezclado con HTTPS, la identificación se transmitirá como texto plano en la URL para todas las solicitudes HTTP (incluso para una solicitud de imagen). Por lo tanto, si el atacante puede leer una sola solicitud HTTP después de que el usuario haya iniciado sesión, conoce el ID de sesión.
Una solución al problema sería separar las dos preocupaciones, mantener la sesión y la autenticación. Luego, puede dejar el ID de sesión sin protección, solo para mantener la sesión, y usar una cookie separada para verificar el estado de inicio de sesión. Esta cookie debe configurarse para enviarse solo a páginas HTTPS.
Además de lo que han dicho Charles y Martin, poner cualquier cosa en la URL hace que sea más probable que se filtre. Esto puede ser a través de un encabezado de referencia en un recurso vinculado, desde el acceso al punto final con registros del historial del navegador, desde el rastreo del historial de fuerza bruta, registros web protegidos de forma inadecuada, etc. Por lo tanto, generalmente no es aconsejable guardar todo lo que desea mantener en secreto en una URL / cadena de consulta.
No he visto a PayPal usando las ID de sesión de servidor en las URL. No hay manera de que sea realmente más seguro que las cookies; la razón por la que normalmente se hacía en el pasado era para admitir navegadores sin las cookies habilitadas. Esto es cada vez menos una preocupación en estos días, y los problemas de usabilidad de no compartir enlaces, además de los ataques de fijación de sesión, significan que la sesión en URL generalmente se evita hoy.
Algo que he visto hace algunos años es que alguien copió una URL (WITH sessionid) en Twitter. Todos los seguidores tuvieron acceso total a la cuenta de esa persona en ese sitio.
Entonces, sí, poner una ID de sesión en la URL es una mala idea.
La ID de sesión se agrega a la seguridad cuando ya se usan cookies. Imagínese si hay un enlace que transfiere dinero de su banco:
Si solo confía en las cookies, este enlace se le puede entregar en un correo electrónico de estafa. Cuando lo abra y haga clic en este enlace, ya que tiene una cookie en su navegador, en realidad será funcional. Usted transferirá con éxito (y sin saberlo) el dinero de su cuenta a la de otra persona.
Si el enlace fuera:
entonces el estafador malintencionado no pudo enviarte el correo electrónico como el de arriba, porque es casi imposible adivinar tu ID de sesión actual.
Lea otras preguntas en las etiquetas web-browser webserver cookies