Seguridad en las sesiones de las aplicaciones Web II -

Funcionamiento habitual de las aplicaciones que utilizan autenticación basada en cookies de sesión:

Sin entrar en las implicaciones de seguridad que tiene, una aplicación que basa el control de acceso de sus usuarios en cookies de sesión suele actuar de la siguiente forma:
Se crea una sesión vacía. (Sin datos asociados.)
Se le asigna esta sesión a un cliente que accede a la aplicación.
En este momento se pueden o no almacenar en la sesión unos datos iníciales sencillos. (Por ejemplo hora de acceso, dirección IP de origen, versión del navegador, etc.)
Se realiza el proceso de autenticación del usuario. (Mediante la solicitud de nombre de usuario y contraseña o mediante otro tipo de mecanismos de autenticación.)
Se almacenan en la sesión los datos relativos al usuario. Su nombre de usuario, su contraseña (si fuese necesario), si el proceso de autenticación fue correcto o no, etc.

Posteriormente la sesión será utilizada para distinguir al usuario legítimo de otros y mantener las variables asociadas a su trabajo con la aplicación.

Como hemos visto, la sesión puede tener varios estados (autenticado y no autenticado). Por tanto la posesión de una cookie de sesión no implica que el usuario se encuentre correctamente autenticado en la aplicación. Ni siquiera indica si el usuario ha pasado ya por el proceso de autenticación.

En muchas aplicaciones, la cookie de sesión se le asigna al usuario en la primera página que visita en el servidor, aunque el momento de la asignación de la cookie puede establecerse en otro punto. Posibles puntos de asignación de la cookie se sesión:
En la primera pagina que visite el usuario. (Sea cual sea dentro de la aplicación.)
En un punto concreto de la aplicación. (Por ejemplo una página de bienvenida.)
Al iniciar el proceso de autenticación. (Por ejemplo en la página del formulario login.)
Cuando ha finalizado el proceso de login. (El identificador de sesión se mantiene oculto hasta el último momento. Esta suele ser la opción más segura.)

Otra característica habitual de las aplicaciones basadas en cookies de sesión es que normalmente utilizan un API externo para el control de sesiones. La mayoría de lenguajes orientados al entorno web (PHP, ASP, Java) cuentan con un API específico para el control de sesiones.

También la mayoría de servidores de aplicaciones ofrecen APIs de este tipo, bien propias o bien derivadas del lenguaje base que utilicen.
Ejemplos de cookies estándar:
BEA WebLogic
------------
Set-Cookie: WebLogicSession=PLLHV8No5ImB2wUo2mupD49Bdo2HxEXq7OjhAAEl1EP6tMr1KbtI-2011799079004677001/-1062729195/6/7001/7001/7002/7002/7001/-1-3433517045111774782/-1062729194/6/7001/7001/7002/7002/7001/-1; path=/
Microsoft IIS
-------------
Set-Cookie: ASPSESSIONIDGQQGQYDC=KDGFBFGBLPNCMIIELPAINNJH; path=/
IBM WebSphere Application Server
--------------------------------
Set-Cookie: sesessionid=ZJ0DMWIAAA51VQFI50BD0VA;Path=/
PHP
---
Set-Cookie: PHPSESSID=d9d9c6a28343e74613d9a901f68c3397; path=/
Esto hace que algunos factores relacionados con la seguridad estén bastante controlados por defecto, como por ejemplo: la aleatoriedad de la cookie, la protección frente a colisiones, posibles errores en el manejo del array interno de variables, etc.

En este sentido el uso de un API centralizado es positivo, sin embargo existe un riesgo en servidores que hospedan varias aplicaciones que comparten el mismo pool de sesiones. En estas situaciones, si el programador no ha sido cuidadoso, pueden aparecer vulnerabilidades derivadas del uso de la misma sesión en 2 o más aplicaciones distintas.


Vulnerabilidades típicas en el manejo de sesiones:

Los errores que se pueden producir en una aplicación cuando se realiza una manipulación de sus cookies de sesión pueden ser muy variados, aunque los más habituales son los siguientes:

Revelación de datos internos en la cookie: Como hemos comentado, el identificador de sesión no debe contener datos internos. Si la cookie incluye información no aleatoria, un atacante puede analizarla y sacar conclusiones sobre el estado interno de la aplicación. Todas las variables relacionadas con la sesión deben ser almacenadas internamente para garantizar su secreto.

Identificador de sesión predecible: Si el identificador de sesión que genera el servidor es predecible, cualquier usuario puede ser suplantado (Session-hijacking) ya que el valor que lo identifica frente a la aplicación, puede ser adivinado y utilizado por cualquier otro usuario.

Autenticación insuficiente: Se produce cuando la aplicación no comprueba correctamente el estado de la sesión del usuario. Es habitual que algunas aplicaciones para dar acceso a secciones protegidas simplemente comprueben que el usuario cuenta con un identificador de sesión, sin comprobar si se ha realizado correctamente el proceso de autenticación y sin comprobar que el estado de la sesión es correcto.

Como hemos visto, la mera posesión de un identificador de sesión no es suficiente para autorizar a un usuario ya que este puede haber conseguido el identificador en otra aplicación del mismo pool o haber obtenido una sesión en blanco.

Reutilización de sesión: Esto se produce cuando la sesión no es correctamente borrada cuando el usuario termina su actividad. De esta forma el usuario puede seguir utilizando la sesión para volver a autenticarse o acceder a otras aplicaciones que comparten el pool de sesiones.

Fijación de sesión (Session-fixation): Técnica de ataque consistente en obtener un identificador de sesión valido y forzar a otro usuario para que lo utilice y así poder suplantarle una vez se encuentre dentro de la aplicación.
En la próxima entrega comenzaremos a analizar los principales ataques sobre las sesiones de las aplicaciones web.

Via S21Sec Labs