No se trata de un ataque específico, sino una clase general de ataques sobre los datos de sesión de un usuario. Puede tomar diferentes formas:
1. Un ataque del tipo man-in-the-middle, en el cual un atacante espía datos de sesión mientras estos viajan por la red (cableada o inalámbrica).
2. Session forging (Falsificación de sesión), en la cual un atacante usa un identificador de sesión (posiblemente obtenido mediante un ataque man-in-the-middle) para simular ser otro usuario.
Un ejemplo de los dos primeros sería una atacante en una cafetería usando la red inalámbrica del lugar para capturar una cookie de sesión. Podría usar esa cookie para hacerse pasar por el usuario original.
3. Un ataque de falsificación de cookies en el cual un atacante sobrescribe los datos almacenados en una cookie que en teoría no son modificables. El Capítulo 12 explica en detalle cómo funcionan las cookies, y uno de los puntos salientes es que es trivial para los navegadores y usuarios maliciosos el cambiar las cookies sin tu conocimiento.
Existe una larga historia de sitios Web que han almacenado una cookie del
tipo IsLoggedIn=1 o aun LoggedInAsUser=jacob. Es trivialmente
simple sacar provecho de ese tipo de cookies.
En un nivel aun más sutil, nunca será una buena idea confiar en nada que se almacene en cookies; nunca sabes quién puede haber estado manoseando las mismas.
4. Session fixation (fijación de sesión), en la cual un atacante engaña a un usuario y logra asignar un nuevo valor o limpiar el valor existente del identificador de su sesión.
Por ejemplo, PHP permite que los identificadores de sesión se pasen en la
URL (por ejemplo,
http://example.com/?PHPSESSID=fa90197ca25f6ab40bb1374c510d7a32).
Un atacante que logre engañar a un usuario para que haga click en un link
que posea un identificador de sesión fijo causará que ese usuario comience
a usar esa sesión.
La fijación de sesión se ha usado en ataques de phishing para engañar a usuarios e inducirlos a ingresar información personal en una cuenta que está bajo el control de atacante. Este puede luego conectarse al sitio con dicho usuario y obtener datos.
5. Session poisoning (envenenamiento de sesión), en el cual in atacante inyecta datos potencialmente peligrosos en la sesión de un usuario — normalmente a través de un formulario que el usuario envía con datos de su sesión.
Un ejemplo canónico es un sitio que almacena un valor de preferencia simple (como el color de fondo de una página) en una cookie. Un atacante podría engañar a un usuario e inducirlo a hacer click en un link que envía un "color" que en realidad contiene un ataque XSS; si dicho color no está siendo escapado, el usuario podría insertar nuevamente código malicioso en el entorno del usuario.
19.5.1. La solución
Existe un número de principios generales que pueden protegerte de estos ataques:
1. Nunca permitas que exista información sobre sesiones contenida en las URLs.
El framework de sesiones de Django (ver Capítulo 12) simplemente no permite que las URLs contengan sesiones.
2. No almacenes datos en cookies en forma directa; en cambio, almacena un identificador de sesión que esté relacionado a datos de sesión almacenados en el back-end.
Si usas el framework de sesiones incluido en Django (o sea
request.session), eso es manejado en forma automática. La única cookie
que usa el framework de sesiones es un identificador de sesión; todos los
datos de la sesiones se almacenan en la base de datos.
3. Recuerda escapar los datos de la sesión si los visualizas en la plantilla. Revisa la sección previa sobre XSS y recuerda que esto se aplica a cualquier contenido creado por el usuario así como a cualquier dato enviado por el navegador. Debes considerar la información de sesiones como datos creados por el usuario.
4. Previene la falsificación de de identificadores de sesión por parte de un atacante siempre que sea posible.
A pesar de que es prácticamente imposible detectar a alguien que se ha apropiado de un identificador de sesión, Django incluye protección contra un ataque de sesiones de fuerza bruta. Los identificadores de sesión se almacenan como hashes (en vez de números secuenciales) lo que previene un ataque por fuerza bruta, y un usuario siempre obtendrá un nuevo identificador de sesión si intenta usar uno no existente, lo que previene la session fixation.
Nota que ninguno de estos principios y herramientas previene ante ataques
man-in-the-middle. Dichos tipos de ataques son prácticamente imposibles de
detectar. Si tu sitio permite que usuarios identificados visualicen algún tipo
de datos importantes debes, siempre, publicar dicho sitio vía HTTPS.
Adicionalmente, si tienes un sitio con SSL, debes asignar a la variable de
configuración SESSION_COOKIE_SECURE el valor True; esto hará que Django
envíe las cookies de sesión vía HTTPS.