¿No puede un atacante cambiar la información de su sesión (o cookie porque está almacenada localmente) y luego engañar al servidor para que sea el usuario legítimo?
Por ejemplo, si un sitio web utiliza el identificador de la base de datos como identificador, el atacante inicia sesión en su cuenta para obtener su cookie. Luego simplemente modifique su ID para hacerse pasar por otro usuario legítimo.
Sí, si puedes adivinar la clave de sesión de otro usuario, entonces puedes convertirte en ellos. Es por esto que necesita tener una clave de sesión impredecible que pueda ser revocada.
Ha habido casos en los que no se han seguido las mejores prácticas, por ejemplo, Moonpig produjo una API que usaba una clave de sesión que era la ID del usuario que se estableció en la creación de la cuenta como un número consecutivo. Esto significaba que podías ser cualquier usuario. Si ese usuario deseaba detenerlo, no podía, ya que es la clave para todas las sesiones en las que participa y no se puede cambiar, ya que es la ID única para ellos dentro de la base de datos Moonpig.
Este es un muy buen ejemplo de cómo hacerlo mal. Las claves de sesión deben ser impredecibles y se pueden tirar (posiblemente para que un usuario tenga muchas claves de sesión).
Como @Mindwin mencionó en los comentarios, la clave de la sesión debe estar en la carga HTTP (cookies o datos del formulario [la mejor práctica está en las cookies]) y no en la URL. Esto se debe a que tener los datos de la sesión en la URL lo hace así que tiene que ponerlos en la URL de cada enlace, le impide continuar una sesión si el usuario se retira y regresa, copiando la URL y enviándola a alguien le da su sesión datos y hay un límite de caracteres que puede ser una URL.
También debes usar HTTPS siempre que sea posible para que un atacante no pueda interceptar la carga útil HTTP y obtener una copia de la clave de sesión de esa manera (así es como funcionó Firesheep).
Sí. Puede.
La información de la sesión se almacena en el lado del servidor (excepto el token de la sesión), mientras que las cookies de la otra manera se almacenan en el lado del cliente (navegador). Así que el atacante podría cambiar el token de la sesión para secuestrar una sesión.
El ataque se conoce comúnmente como secuestro de sesión a través de la manipulación de cookies. Pero el atacante debe usar un token de sesión válido que se puede encontrar fácilmente si un sitio está mal configurado. Un sitio mal configurado puede almacenar un token en la url, o no genera uno aleatorio, etc ...
Aquí hay cuatro métodos principales utilizados para secuestrar una sesión:
La mejor práctica para protegerse sería almacenar el token de sesión dentro de una cookie. Sin embargo, si el token de sesión no coincide con criterios sólidos como aleatoriedad, singularidad, resistencia al análisis estadístico y criptográfico, es posible que un atacante manipule la sesión.
Parece que hay cierta confusión entre los cookeis y la información de la sesión aquí, así que comencemos por ordenar eso:
Las cookies se almacenan en el cliente. Por lo tanto, el usuario puede cambiarlos si lo desea.
Información de sesión se almacena en el servidor. Eso significa que el usuario no puede cambiarlo.
"Nunca confíes en el cliente" es una regla antigua en seguridad. Eso significa que nunca puede confiar en la información de las cookies, solo porque la cookie del nombre de usuario tiene el valor "Alicia" no significa que "Mallory" no fue la que inició sesión.
Por esa razón, la información vital generalmente no se almacena en las cookies en el cliente, sino en la sesión en el servidor. A continuación, utiliza una cookie con un ID de sesión para conectar los dos. El ID de sesión es un número aleatorio largo. Si el ID de la sesión de Alice es 20349023490324 , el servidor tendrá toda la información de su sesión (como su nombre de usuario) archivada bajo ese número.
El usuario podría cambiar el ID de sesión, pero dado que hay tantos ID de sesión posibles, es extremadamente improbable que adivine un ID que realmente esté conectado a un usuario.
En algunos casos, es posible que desee almacenar datos en cookies de todos modos. Para evitar que el usuario juegue con ellos, puede firmarlos con una clave que solo tenga en el servidor. Dado que el usuario no tiene la clave, el servidor podrá detectar cualquier cambio en las cookies ya que la firma ya no coincidirá.
Los identificadores de sesión deben ser criptográficamente seguros en el sentido de que no puedes simplemente adivinarlos. Por lo general, es solo un número de 128 bits de aspecto aleatorio y no tiene ninguna conexión obvia con el usuario que está identificando. Entonces, para hacerse pasar por otra persona, necesitas encontrar la ID de ese usuario. Hay formas de hacerlo, pero son diferentes a "simplemente modificarlo" para convertirse en otra persona.
Sin embargo, el servidor tiene una tabla que coincide con la información real del usuario y el ID de sesión que pertenece a ese usuario para que pueda usar esa información. Pero nunca puede conocer la ID de sesión de otra persona solo con mirar la que está almacenada en su navegador.
Muchas respuestas parecen estar diciendo que si la identificación de la sesión implica aleatoriedad, singularidad, resistencia al análisis estadístico y criptográfico o algo así, entonces está bien. Esto no es realmente cierto (como en no completo). Una cookie (que contiene esa identificación) no tiene que ser adivinada porque puede ser literalmente interceptada y reutilizada por un atacante. También hay casos raros pero posibles de un sistema de transferencia de proxy o dmz que mezcla cookies (lo he visto). Por este motivo, además de lo mencionado anteriormente, es probable que desee que su propia aplicación haga algo como:
Al iniciar sesión, el sistema debe almacenar el agente de usuario y la dirección IP de la solicitud en la sesión del lado del servidor. Verifique todas las solicitudes posteriores y verifique que los valores entrantes para ip y user-agent coincidan con los almacenados en la sesión. Si no, invalide la sesión del lado del servidor y redirija a la pantalla de inicio de sesión. Esto evitará que el secuestrador obtenga la entrada. Como un efecto secundario aceptable, el usuario legítimo también será expulsado (solo cuando se produce un intento de secuestro), pero simplemente pueden volver a iniciar sesión.
Sí, los sitios que no usan cookies con la marca de seguridad activada pueden sufrir el secuestro de cookies (en la misma red) y, por lo tanto, otros usuarios pueden suplantarlo. Otra medida de seguridad que el sitio puede usar es hacer un seguimiento de las sesiones de los usuarios y verificar cuántas sesiones están abiertas al mismo tiempo. Espero que te responda :)
Lea otras preguntas en las etiquetas web-application cookies session-management session-fixation