Feed de Edgaragg

Artículos relacionados

Facebook Share

Share on facebook

Designed by:
SiteGround web hosting Joomla Templates
Buenas prácticas en el manejo de sesiones en aplicaciones web
Buenas prácticas en el manejo de sesiones en aplicaciones web - Buen manejo de sesión PDF Imprimir E-mail
Escrito por edgaragg   
Lunes, 08 de Septiembre de 2008 14:48
Indice del artículo
Buenas prácticas en el manejo de sesiones en aplicaciones web
Manteniendo el estado
ID de sesión en el URL
Uso de campos ocultos en un formulario
Cookies
El ID de Sesión
Robo de sesión
Fallas comunes
Buen manejo de sesión
Conclusiones
Todas las páginas

Buen manejo de sesión

Dependiendo del propósito de la aplicación, hay varios métodos para implementar el manejo de sesiones disponibles para los desarrolladores y algunas aplican mejor que otras.  Para aplicaciones que requieren el máximo nivel de seguridad, las opciones son limitadas y requieren una mezcla de los métodos descritos anteriormente.  El siguiente es uno de los métodos considerados más seguros para manejar la sesión, pero es complicado y dificil de implementar correctamente.   El método se basa en el uso de tres fuentes de información del ID de sesión.  Esta información está almacenada y es enviada en el URL, en el HTTP_REFERER y en cookies.

Cuando un cliente se conecta con una aplicación inicialmente como invitado (guest) se le asigna un identificador de usuario (ID1) y esta información se coloca en el URL.  El URL contiene tambien un identificador aleatorio (ID2) de la página vista.  Un tercer identificador (ID3) se genera y se almacena en cookies cuyo tiempo de vida durará hasta que la sesión expire.   Si el servidor no registra actividad del navegador, el ID3 es revocado.

Los pasos son:

  1. El cliente navega a una página (http://www.edgaragg.com
  2. El cliente es redireccionado a una nueva página cuyo URL contiene los identificadores de sesión ID1 (usuario = 22992Hx982j) e ID2 (página 28200492)

    http://www.edgaragg.com?user=22992Hx982j&cpage=28200492

  3. Como parte de la respuesta de la página, se envía un cookie (ratro de usuario = YU389kj02wwn

  4. Set-Cookie: UserTrack="YU389kj02wwn"; path="/"; domain="www.edgaragg.com"; expires="2000-01-01 00:00:00GMT"; version=0

    En la páagina presentada al cliente, es posible que existan vínculos a otras páginas en la misma aplicación, cada vínculo debe ser generado dinamicamente de tal forma de incluir un identificador de página aleatorio (el cual estará almacenado).  Como un usuario no autenticado, el identificador de página cambiará mientras ID1 e ID3 se mantengan iguales.  El identificador ID3 cambiará cuando el usuario se autentique en la aplicación.

    <a href="/pagina.php?user=22992Hx982j&npage=8494994">Link 1</a>
    <a href="/pagina.php?user=22992Hx982j&npage=3939948">Link 2</a>
    <a href="/pagina.php?user=22992Hx982j&npage=1938410">Link 3</a>


    Para páginas que contengan un formulario que deba ser enviado, dicho formulario debe contener campos ocultos (hidden) para almacenar los identificadores ID1 e ID3.  Si la información a enviar contiene datos confidenciales, entonces los datos deben ser enviados usando HTTPS.  Es importante notar en el ejemplo que el atributo action especifica el HTTPS y el URL completo.

    <FORM METHOD=POST ACTION="https://www.edgaragg.com/post/pagina.php">
    <INPUT TYPE="hidden" NAME="user" VALUE=" 22992Hx982j">
    <INPUT TYPE="hidden" NAME="cpage" VALUE="28200492">
    <INPUT TYPE="text" NAME="data" MAXLENGTH="100">
    <INPUT TYPE="submit" NAME="Enviar">


  5. Todas las páginas o envios de datos a través de formularios echos desde el navegador deben incluir el ID de sesión en cookies (ID3)
  6. La aplicación debe tomar los tres identificadores (ID1, ID2 e ID3) y chequear si son válidos para la petición correspondiente y que la sesión no haya sido revocada.  Si la información no es correcta, la página se redirecciona a la página principal con tres nuevos identificadores y los anteriores son revocados.
  7. Cuando el cliente envía una petición o sigue un hipervínculo, se incluye un valor en el HTTP_REFERER.  Este valor representa el URL que el cliente visitó anteriormente.  La aplicación debe poder validar si el identificador de página anterior (ID2) es el correcto precursor de la nueva página solicitada.  Si no es así, entonces no se llegó a la página por el camino correcto, lo que puede significar un ataque en progreso.
  8. Si los identificadores son correctos, la nueva página es presentada, se actualiza el ID2 (página actual = 88773002) mientras que ID1 e ID3 se mantienen igual 

    http://www.edgaragg.com?user=22992Hx982j&cpage=88773002
  9. La nueva página contiene identificadores únicos para todos los vínculos existentes.  Debe existir un botón de volver a la página anterior. Sin embargo, para volver a la página anterior se debe generar de nuevo un identificador de página.  El botón de "ir atrás" del navegador no funcionará en la aplicación.
  10. Cuando la aplicación requiera autenticación de parte del usuario, todos los datos se enviarán a través de un canal encriptado (HTTPS), si el usuario es autenticado exitosamente, un nuevo identificador de cookies (ID3) es generado y el anterior es revocado del servidor.  Mientras el usuario esté autenticado, todos los datos serán enviados usando HTTPS hasta que el usuario decida salir (log out).
  11. La aplicación debe ser capaz de asociar el ID3 con el tipo de comunicación (HTTP o HTTPS) e inmediatamente revocar todos los ID de sesión (ID1, ID2 e ID3) si el nuevo ID3 es usado para acceder a un recurso no seguro de la aplicación.  El uso incorrecto de los IDs de sesión llevarán al usuario a la página principal, y se reiniciarán los identificadores como se mencionó anteriormente.
  12. El usuario debe tener la facilidad de finalizar la sesión, lo cual resulta en la revocación automática de todos los identificadores.  Como adición,  es una buena práctica asegurarse que tanto los tags Meta asociados con caché y las opciones de caché de HTTP sean seteadas para expirar en una fecha pasada, de tal forma que ningún contenido sea almacenado en el computador del cliente.

Es importante señalar que al utilizar la información de sesión en el URL, se hace más dificil llevar a cabo un ataque de tipo cross-site scripting en el URL.  Al asignar identificadores únicos aleatorios a cada página y vínculos entre las página con un identificador existente solo en ese momento, se muy complicado para un atacante llevar a cabo un ataque de fuerza bruta.  Sin embargo, este método de manejo de sesión hace uso de cookies, los cuales no funcionarán si el navegador los tiene deshabilitados.



Actualizado ( Martes, 23 de Septiembre de 2008 14:38 )