| Artículos | 01 JUL 2006

Gestión de sesiones

Tags: Histórico
Curso de seguridad (V)
Gonzalo Alvarez.
En este curso de seguridad en aplicaciones web en cinco entregas se explicará algunos de los conceptos más importantes para protegerse frente a los ataques más frecuentes y las amenazas más graves.
Una vez que el usuario se ha autenticado ante el servidor, se necesita algún mecanismo para ligar la identidad del usuario autenticado con las sucesivas peticiones que realiza. En esta última entrega se analizan las posibilidades existentes en los entornos web actuales, las amenazas a las que están expuestas y las contramedidas a implantar para garantizar la seguridad.

Nivel de dificultad: Medio
Objetivo: Asegurar la identidad de los visitantes al sitio web una vez autenticados
Herramientas: Las herramientas incluidas con el software del servidor web

Tradicionalmente, la gran ventaja de la autenticación mediante formularios es que no existen restricciones respecto al lugar donde almacenar las credenciales de los usuarios: archivos XML o de texto, una tabla en una base de datos, un directorio LDAP, cualquier almacén que se pueda imaginar; y tampoco existen limitaciones en cuanto al número de usuarios de la aplicación. La contrapartida reside en que el diseñador de la aplicación debe realizar algún seguimiento de la identidad de los usuarios entre peticiones sucesivas. Una vez que el usuario se ha autenticado tras entregar sus credenciales a través de un formulario web, el servidor necesita algún mecanismo para saber si la petición de una página, que ya no viene acompañada de credenciales, procede de un usuario autenticado y de qué usuario en concreto, para poder presentarle sus datos si procede y no los de algún otro usuario.
El protocolo HTTP, a diferencia de otros protocolos de Internet como Telnet, SMTP, POP3 o FTP, es un protocolo sin estado, es decir, cuando un servidor web recibe dos peticiones sucesivas de un cliente no sabe si provienen del mismo usuario o de dos usuarios distintos, a no ser que se habilite un mecanismo que permita: a) identificar al cliente, y b) retener información del cliente. Este mecanismo es lo que se conoce como gestión de sesión.
En definitiva, el servidor debe ser capaz de autenticar al usuario, para lo cual éste suministrará sus credenciales. Una vez verificadas con éxito, el servidor debe ser capaz de identificarlo, es decir, de asociar múltiples peticiones sucesivas con el usuario que acaba de autenticarse. Esta identificación se consigue reteniendo algún dato que lo identifique unívocamente y, por tanto, lo distinga de cualquier otro usuario, incluso aunque ambos estén utilizando el mismo cliente físico (el mismo navegador en el mismo ordenador). Este identificador suele bautizarse como testigo, aunque otros nombres comunes son ticket, token o ID de sesión.

Requisitos del testigo
Los testigos deben poseer una serie de características con el fin de permitir identificar correctamente las sesiones y evitar ataques:
- Identificar unívocamente al cliente: No puede haber dos usuarios con el mismo testigo simultáneamente, ya que uno podría acceder a los datos del otro.
- Ser difícil de crear: Solamente el servidor debe ser capaz de crear el testigo mientras que los usuarios deberían ser totalmente incapaces de predecir o generar un testigo válido.
- Caducar: Los testigos deberían tener un tiempo de vida limitado.
- Viajar por un canal cifrado: Dado que poseer el testigo permite suplantar la identidad del usuario legítimo, deben transmitirse siempre a través de un canal cifrado con SSL.
- Crearse después de que el usuario se haya autenticado, no antes.
Clasificación de los testigos
Existen dos grandes formas de clasificar a los testigos: en función de su método de transporte (cookie, URL, formulario) y en función de la información almacenada (índice o datos). Por supuesto, pueden existir combinaciones entre ambos tipos de testigos: el testigo viaja en una cookie que almacena los datos cifrados, el testigo se transmite en la URL y apunta a un conjunto de variables de sesión en memoria, etc. Ambas clasificaciones pasan a explicarse a continuación.

Mecanismo de transporte
Atendiendo al mecanismo de transporte, el testigo podría viajar en una cookie, en la URL o en variables ocultas dentro de formularios. Aunque existe un acalorado debate en torno a la cuestión de si es más seguro utilizar cookies o la URL como medio de transporte, la forma más extendida a día de hoy es la cookie. Existen dos tipos de cookies:
- Persistentes: Se conservan en el disco duro, durante un tiempo especificado en su fecha de caducidad. Aunque el usuario apague el ordenador, estarán disponibles la próxima vez que visite el sitio que las envió.
- De sesión: Solamente se almacenan en memoria durante el tiempo que el usuario tenga activa la sesión con el navegador. Basta con que cierre el navegador para que la cookie desaparezca.
En el caso de Internet Explorer, las cookies persistentes se almacenan en el directorio C:\Documents and Settings\<usuario>\Cookies, cada una en un archivo de texto separado. Pueden editarse con el Bloc de notas y examinar su contenido. Un atajo para abrir esta carpeta consiste en seleccionar Inicio• Ejecutar y escribir cookies. En Firefox se localizan en el archivo cookies.txt, ubicado en la carpeta C:\Documents and Settings\<Usuario>\Datos de programa\Mozilla\Profiles\<cadena aleatoria>. Todos los navegadores incorporan utilidades para visualizar y eliminar cookies, y algunas extensiones de Firefox permiten incluso editarlas, como Add & Edit Cookies (addneditcookies.mozdev.org), mostrada en la Figura 1.
Las cookies de sesión pueden verse utilizando comandos de JavaScript en el navegador:
javascript:alert(document.cookie)
El protocolo HTTP utiliza dos cabeceras para las cookies:
- Set-Cookie: Utilizada por el servidor para indicarle al navegador los contenidos de la cookie que debe almacenar en su disco duro.
- Cookie: Utilizada por el navegador en cada petición HTTP que realice al servidor, siempre y cuando posea alguna cookie procedente de ese mismo servidor.
A continuación se muestra un envío de información desde el servidor que solicita la escritura de una cookie en el disco duro del usuario:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sat, 25 May 2006 17:58:26 GMT
Content-Length: 1959
Content-Type: text/html
Set-Cookie: ASPSESSIONIDGQGQGMIG=PHFLKMLBCEDAAOMDDEPOLBKN; path=/
Cache-control: private
<HTML>
...
Y ahora una petición del navegador, acompañada de las cookies que ha recibido de dicho servidor:
GET /default.asp HTTP/1.1
Host: www.gonzaloalvarez.com
Content-Length: 200
Connection: Keep-Alive
Cookie: ASPSESSIONIDGQQGGVDY=NOBPAJDCAJFCCKHFFOMMDHCN
Se recomienda utilizar nombres completos para los campos de dominio y ruta de acceso y separar netamente las cookies de autenticación de las cookies de personalización, si las hubiera. En concreto, las de autenticación deberían llevar también los atributos HttpOnly y Secure.
No se considera una buena idea proporcionar a los usuarios la posibilidad de saltarse la autenticación para entrar en el sitio protegido, por lo que las cookies con el testigo de sesión nunca deberían guardarse en disco. Esta opción típicamente se designa bajo el texto “Recordarme la próxima vez” o “No volver a pedir mis credenciales en el futuro” o leyendas similares (véase la Figura 2). Detrás se oculta el mecanismo para almacenar el t

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información