Buenas prácticas en el manejo de sesiones en aplicaciones web Imprimir
Escrito por edgaragg   
Lunes, 08 de Septiembre de 2008 14:48

 

La naturaleza sin estado del protocolo HTTP hace que las organizaciones y los desarrolladores tengan que buscar formas para identificar univocamente a un visitante en una aplicación web.  Varios metodos han sido propuestos y usados, sin embargo, el más utilizado es el que hace uso de un ID de sesión único.  Desafortunadamente, en muchos casos se han aplicado incorrectamente estos ID de sesión haciendo que la aplicación "segura" esté abierta a posibles ataques.

Entendiendo la situación

Hoy en día la mayoría de las organizacione han realizado una cantidad considerable de inversiones en su presencia en Internet.  Para estar organizaciones, Internet se a convertido en una excelente forma de mostrar sus productos a sus clientes y constituye una forma de ofrecer una presencia 24x7.  En la mayoría de los casos estos servicios son ofrecidos usando HTTP simple.   Sin embargo, debido a la forma en que el protocolo HTTP trabaja, no existe niguna facilidad para identificar univocamente a un usuario a través de una aplicación web.   De esta forma, los desarrolladores han tenido que idear métodos para lograr manejar el estado de una sesión sobre un protocolo que por definición no lo soporta.

La forma más común de lograr este objetivo es usar un identificador único de sesión el cual viaja hacia el navegador y de vuelta al servidor en cada petición (request).  Sin embargo, resulta relativamente facil para un hacker adivinar este identificador y usarlo para robar la identidad del usuario.

Una forma de manejar las sesiones es solicitar al usuario que se identifique en el sitio web usando un nombre y contraseña para las páginas restringidas.  De esta forma, no solo se estaría identificando univocamente a cada usuario sino que también se estaría identificando a los usuarios autenticados en la aplicación.

 Ahora bien, el método a utilizar para manejar el ID de sesión en una aplicación web y la prevención de posibles ataques dependerá de la respuestas a las siguientes preguntas:

  1.  ¿Dónde y con qué frecuencia se espera que los usuarios autenticados usarán la aplicación web?.
  2. ¿Hásta que punto necesita la organización manipular el estado de una sesión?
  3. ¿Qué nivel de daño podria causar a un usuario autenticado el ataque de un hacker (con el posible robo de identidad)?
  4. ¿Cuánto tiempo le tomaría a una persona romper el método de manejo de sesión?
  5. ¿Cómo podría la aplicación identificaro responder a un posible ataque?
  6. ¿Cuál sería el impacto en la usabilidad de la aplicación si se usa una versión encriptada de HTTP (HTTPS?
  7. ¿Cuál sería el costo en la reputación de la organización si se rompe con el método de manejo de sesión y esta información se hace pública?
Respondiendo a estas preguntas una organización puede evaluar la conveniencia y riesgos financieros que puede traer el uso o implementación de un método de manejo de sesión pobre.



Manteniendo el estado

Tipicamente, los procesos para manejar el estado de una aplicación web es a través del uso de un ID de sesión.  Dichos identificadores son usados para identificar univocamente a un usuario en la aplicación, mientras que del lado del servidor, existen procesos para asociar este identificador a un nivel de acceso.  Esto significa que una vez que el usuario ha sido autenticado, se puede usar el ID de sesión como un ticket de entrada que permitirá al usuario entrar en cada página sin necesidad de volver a tipear su usuario y contraseña.

Los desarrolladores tienen tres métodos disponibles para enviar y recibir el ID de sesión en una aplicación web:

  • Colocar el ID en el URL de la página, el cuál es recibido por la aplicación vía GET cuando el cliente hace clic en vínculos ubicado en la página.
  • Almacenar el ID en ciertos campos de un formulario, el cual será enviado a la aplicación vía POST.  Tipicamente se usan campos de tipo hidden para almacenar esta información.
  • A través del uso de Cookies
Cada uno de estos métodos posee sus ventajas y desventajas, uno puede ser más apropiado que el otro según sea el caso.  La selección de un método u otro depende del tipo de aplicación que se está desarrollando y el tipo de personas que harán uso de la aplicación.  A continuación se muestra con más detalle cada uno de estos métodos.  Es importante para un desarrollador entender las limitaciones e implicaciones de seguridad de cada uno de estos métodos.



ID de sesión en el URL

 

El ID de sesion se envía como parte del URL de la página y el servidor la recibe vía GET cuando el usuario hace clic en un vínculo de la página.

Ejemplo:  http://www.edgaragg.com/index.php?ID=883002889306

 Ventajas:

  • Puede ser usado incluso si el navegador del cliente tiene una seguridad alta y tiene deshabilitada las cookies
  • Si el ID de sesion es asociada permanentemente con el browser y el computador, un usuario podria iniciar sesion simplemente guardando la pagina en los favoritos o marcadores.
  • Dependiendo del navegador, la informacion de la sesion se envia en el campo HTTP_REFERER.  Esta informacion puede ser usada para verificar que el usuario a seguido una ruta determinada para llegar hasta dicha pagina a traves de la aplicacion web, previniendo de esta forma ciertos ataques comunes.

 Desventajas:

  • Cualquier persona en el mismo computador podria revisar el historial del navegador o los favoritos y seguir el mismo URL, de esta forma estaria usando la sesion de otro usuario.
  • La informacion del URL puede ser almacenada en un Log por intermediarios (Firewalls o servidores proxy), cualquier persona con acceso a esos logs puede ver el URL y usar esa informacion para llevar a cabo un ataque.
  • Es bastante facil para cualquier persona cambiar el URL y el ID de sesion asociado usando el navegador, asi que las habilidades y los equipos necesarios para llevar a cabo un ataque son minimos.
  • Cuando el usuario navega a otro sitio web, el ID de la sesion puede ser enviada a ese sitio web a traves del campo HTTP_REFERER

 

Uso de campos ocultos en un formulario

 

El ID de sesión es almacenado en un campo oculto (hidden) y enviado al servidor cuando se envía el formulario vía POST.  

Ejemplo:

<FORM METHOD=POST ACTION=”http://www.edgaragg.com”>
<INPUT TYPE=”hidden” NAME=”sessionid” VALUE=”
883002889306”> 

Ventajas:

  • No es tan obvio como enviar el ID en el URL, por lo tanto requiere un mayor nivel de conocimiento para poder detectar el ID para poder usarlo en un ataque.
  • Permite a los usuarios almacenar el URL de la página sin proveer información sobre el ID de sesión.
  • Puede ser usado incluso si el navegador del cliente tiene una seguridad alta y tiene deshabilitada las cookies.

Desventajas:

  • A pesar de que requiere un mayor nivel de conocimiento, se puede llevar a cabo ataques usando herramientas disponibles en la red.
  • El contenido de la página tiende a ser más compleja, ya que se debe almacenar mayor cantidad de información en la página (sin tomar en cuenta que hoy en día se hace uso de scripts y aplicaciones flash embebidas en la página), lo cual hace que la página sea mucho más grande en tamaño, y se tenga que enviar mayor cantidad de información al navegador del cliente, dando la sensación de lentitud en la página.
  • Debido a malas prácticas de programación, un fallo en el chequeo del método de envío (GET o POST) en el lado del servidor, hace que una información que debe ser enviada vía POST se agregue en el URL de tal forma que esta sea enviada via GET.

 

Cookies

 

Cada vez que un navegador tiene acceso al contenido de un dominio particular o URL, si existe una cookie, se espera que el navegador envíe cada cookie con informacion relevante como parte de la petición (request).  Las cookies son usadas para preservar información en el navegador mientras el usuario navega por las páginas de una aplicación web y para mantenerla durante ciertos periodos de tiempo.  Las cookies pueden crearse para que expiren después de cierto tiempo, pudiendo configurarse para que expire al finalizarse la sesión.  Estas cookies son conocidas como "persistentes" y son almacenadas en el disco duro del computador del usuario en una ubicación predefinida por el navegador o el sistema operativo.  Al omitir la información sobre cuando expira la cookie, esta es almacenada en memoria y debe ser eliminada al cerrarse el navegador.

Ejemplo: (Esto es parte de la respuesta enviada por el servidor al navegador cliente)

Set-Cookie: sessionID=”883002889306”; path=”/”; domain=”www.edgaragg.com.com”; expires=”2008-09-01 00:00:00GMT”; version=0 

Ventajas:

  • El uso cuidadoso de cookies persistentes puede ser usado para regular el acceso de los usuarios a través del tiempo.  Puede ser usado para implementar la funcionalidad de recordar al usuario, de tal manera que este no tenga que autenticarse cada vez que quiera usar la aplicación.
  • Hay mas opciones disponibles para manejar los timeouts de la sesión.
  • La funcionalidad de las cookies está disponible en la mayoría de los navegadores, así que no hay que codificar nada especial para asegurarse que la información del ID de sesión almacenada en las cookies sea enviada desde el servidor al navegador y viceversa.

Desventajas:

  • Una práctica de seguridad común hoy en dia es deshabilitar el uso de cookies.
  • Las cookies persistentes son almacenadas como simples archivos de texto en el computador del usuario, así que resulta relativamente fácil copiarla a otros computadores.  Así que dependiendo del nivel de acceso al directorio donde se encuentran las cookies, puede resultar más o menos fácil para otros usuarios del mismo computador robar la información de las cookies y usarla para robar la identidad del usuario.
  • Las Cookies tienen limitación de tamaño, así que no pueden ser usadas para almacenar grandes cantidades de información del estado de la sesión.
  • Las Cookies son enviadas con cada página y-o archivo solicitado por el browser usando la directiva SET-COOKIE

El ID de Sesión

Un aspecto importante en el manejo del estado en una aplicación web es la "fuerza" del ID de sesión.  Como este identificador es usado para hacer un seguimiento al usuario a través de la aplicación web, los desarrolladores deben asegurarse que dicho ID debe cumplir con ciertos criterios para que estos no sean comprometidos usando técnicas predictivas o ataques de fuerza bruta.  La dos características más importantes de un ID de sesión son la aleatorieddad y la longitud.

Aleatoriedad del ID de sesión:

Es importante que el ID de sesión sea generado de una forma que no pueda ser predecida, así que la aplicación debe utilizar un método lo suficientemente fuerte para generar identificadores aleatorios.  Es vital que un algoritmo criptográfico fuerte sea usado para generar un ID de sesión para un usuario autenticado.  No es aconsejable usar algoritmos lineales que usen variables fáciles de predecir como la fecha, hora o dirección IP del cliente.

En otras palabras, el ID de sesión debe cumplir con los siguientes criterios:

  • Debe parecer aleatorio.  Debe pasar pruebas de aleatoriedad.
  • Debe ser impredecible.  Tiene que resultar prácticamente imposible adivinar el siguiente ID a generar, y dado el algoritmo y la información del hardware del cliente no se pueda generar el ID actual y los anteriores.
  • No debe ser reproducible bajo las mismas circustancias.  Si el mismo generador es usado dos veces usando exáctamente la misma entrada, los identificadores generados deben ser distintos y no relacionados.

Longitud del ID de sesión:

Es importante que el ID de sesión sea lo suficientemente largo para hacer prácticamente infactible el uso de un ataque de fuerza bruta para generar un ID de sesión válido en un tiempo razonable.  Dado la capacidad de procesamiento y el ancho de banda actual, un ID de sesión de 50 caracteres es recomendable, pero si es posible generarlos con una longitud mayor es mucho mejor.

La longitud del ID de sesión depende de ciertos factores:

  • Velocidad de conexión. Un ID de sesión muy largo requiere un tiempo adicional para poder ser enviado hacia y desde el cliente.
  • Complejidad del ID.  Usar ID de sesión numéricos no es lo mismo que usar ID alfa-numérico para un ID de la misma longitud.  Al tener más combinaciones usando un ID alfa-numérico, este es mucho más dificil de predecir.


Robo de sesión

Como un ID de sesión es generado para identificar univocamente a un usuario y poder hacerle seguimiento en una aplicación web, cualquier atacante que obtenga ese ID puede ser potencialmente capaz de enviar esa información y de esta forma, robar la identidad de alguien más.  Por lo general un atacante posee tres métodos para hacerse con el ID de sesión, estas son: Observación, fuerza bruta y confianza mal dirigida.

Observación:

Por definición, el tráfico HTTP viaja por la web en forma de texto plano, sin encriptación.  Eso implica que cualquier dispositivo que se encuentre en la misma red o en el camino por el que viajan los paquetes HTTP, puede observar el tráfico y obtener el ID de sesión.  Una forma de prevenir la observación del tráfico es usar el protocolo HTTP seguro o HTTPS

Fuerza bruta:

Si el ID de sesión es generado o presentado de una forma tal que resulte predecible, resulta relativamente fácil para un atacante efectuar intentos repetidos para intentar adivinar el ID de sesión.  Dependiendo de la aleatoriedad y longitud del ID este proceso puede tomar poco tiempo, incluso unos cuantos segundos.

Confianza mal dirigida:

En circunstancias ideale, un navegador debe solo intercambiar la información del ID de sesión con un único sitio de confianza.  Desafortundamente, hay ciertas ocasiones en los que este no es el caso.  Por ejemplo, el campo HTTP_REFERER puede enviar el URL completo, y en ciertas aplicaciones, el URL puede contener la información del ID de sesión.

Otro método ampliamente utilizado utilizando caminos de confianza son los ataques de HTML embebido y el Cross Site Scripting  (CSS o XSS).  A través de la inclusión de código HTML o scripts, es posible robar el ID de sesión, sin importar si el método de manejo de sesión es vía GET, POST o por Cookies.

 


Fallas comunes

Mientras que el manejo de sesiones en la web es importate para el seguimiento de los usuarios y permitir la navegación a través de una aplicación, el uso más crítico es mantener la información del estado de un usuario autenticado mientras el lleva cabo las funciones que la aplicación le provee.  Para la banca en línea y tiendas en línea, usar un método fuerte de manejo de sesión es crucial para el éxito de esas empresas.

A continuación se presenta una lista de los fallos más comunes que se pueden encontrar al manejar la sesión de una aplicación web:

ID de sesión predecibles:

Es la más común de las fallas, como se describión anteriormente, la causa de esto es la falta de aleatoriedad y el tamaño del ID.

  • ID de sesión secuencial.  Cada vez que un usuario distinto hace uso de la aplicación se genera un nuevo ID secuencial.  Esto hace bastante fácil a un atacante robar la identidad de un usuario simplemente observando su ID de sesión y cambiandolo por un sumando o restando un valor pequeño.
  • ID de sesión muy cortos.  Lo cual permite explorar todos los ID de sesión posibles con un ataque automatizado antes de que expire la sesión.
  • Uso de técnicas de hash comunes.  A pesar de que los métodos hash pueden producir un ID de sesión aparentemente único, estos métodos son bastante conocidos y hay que tener cuidado de no usar información predecible para generar el hash.  Por ejemplo, puede generarse el hash usando la información de la hora local o el IP del cliente.  Por lo que usando el mismo método de hash, un atacante podría generar una cantidad de claves de hash basadas en la hora local y usar una técnica de fuerza bruta para robar cualquier sesión.
  • Ofuscación del ID de sesión.  Se refiere al uso de métodos particulares para ofuscar ciertos datos y usarlos como parte del ID de sesión.  No es buena práctica incluir el nombre del cliente u otra información confidencial para generar el ID de sesión.

Transmisión insegura:

Para ciertas aplicaciones (como la banca en línea) es crucial que toda la información confidencial y la información de la sesión sea transmitida de forma segura sin que exitan terceros que puedan observar dicha información para usarlo posteriormente en un ataque.  Desafortunadamente muchos paquetes comerciales han fallado en el pasado al asegurar la integridad de la sesión debido a transmisiones inseguras.

  • Usar encriptación al enviar información de la sesión.  Como se mencionó anteriormente, hay muchos casos en los que la información de un usuario puede ser registrada si no se envía a través de un canal encriptado como HTTPS.  Esto resulta muy importante en aplicaciones que requieren de un alto grado de confidencialidad.  Si se usa el método de las cookies para enviar la información del ID de sesión, se debe tomar en cuenta que el navegador enviará el ID de sesión en cada solicitud (request), incluyendo gráficos y otros documentos, lo cual podrían ser solicitados por un canal que no sea seguro.
  • Usar diferentes ID de sesión cuando el usuario cambia entre componentes seguros y no seguros de la aplicación.  En otras palabras, nunca se debe usar el mismo ID de sesión cuando el usuario está autenticado y cuando no lo está.  De nuevo, hay que asegurarse que el ID de sesión generado en la parte segura de la aplicación no sea predecible y no esté basado en el ID anterior.

Tiempo de vida de la sesión:

Para una aplicación segura, toda la información de la sesión debe tener un tiempo de vida y debe permitir al cliente cancelar la sesión o revocarla en el servidor.

  • Cancelación por parte del cliente: Muchas aplicaciones fallan al no permitir al usuario tener un método de cancelación de sesión como el "log out".  Si la intención es permitir al usuario conectarse desde cualquier sitio, se debe tener cuidad de que otro usuario puede usar el mismo computador, revisar el historial, y si la sesión no ha sido cancelada, puede retomar la conexión actual con la aplicación.
  • Timeout de sesión. Otra vez, tomando en cuenta que un usuario puede conectarse desde un computador compartido, es importante que la sesión tenga un periodo de inactividad establecido, después del cual la sesión automaticamente expira.  En condiciones ideales, la aplicación debe ser capaz de monitorear el periodo de inactividad para cada ID de sesión y borrar o revocar la sesión cuando el tiempo de inactividad sea alcanzado.
  • Revocación de la sesión en el servidor.  En ciertos casos puede ser necesario cancelar una sesión desde el servidor, por ejemplo, cuando un usuario deja la parte insegura de la aplicación para entrar en la parte segura (se autentica) y se genera un nuevo ID.  Asi mismo, el servidor puede registrar ciertos tipos de ataques y revocar la sesión asociada al usuario atacante.

Verificación de la sesión:

Los procesos para manejar los ID de sesión deben ser robustos y capaces de detectar ataques y manejarlos correctamente comprobando lo siguiente

  • Longitud del ID de sesión.  Se debe comprobar que el contenido del ID de sesión es del tamaño y tipo adecuados y que la calidad de la información sea verificada antes de ejecutar cualquier otro proceso.  Por ejemplo, al revisar el tamaño del ID se puede ser capaz de identificar el envío de un ID de gran tamaño que podría constituir un ataque de tipo Buffer Overflow.  Asi mismo, se debe asegurar que el ID de sesión no contiene información no esperada.  Por ejemplo, si la sesión se almacena en una base de datos, hay que tener cuidado de que el ID de sesión no posea caracteres que puedan ser interpretados como parte de una consulta de SQL, lo que podría constituir un ataque de tipo inyección SQL.
  • Fuente del ID de sesión.  Cuando se usa el método HTTP POST para enviar la información de la sesión, la aplicación debe ser capaz de discernir cuando la sesión fué enviada desde el cliente usando efectivamente el método POST y no a través del método GET manipulado.  Convertir un HTTP POST en HTTP GET es un método común de llevar a cabo ataques de tipo Cross-site scripting y otros ataques de fuerza bruta.

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.


Conclusiones

La naturaleza estática de HTTP requiere que las organizaciones usen su propio método para manejar del estado a través de sesiones.  Mientras hay una variedad de formas de implementar una solución para manejo de sesiones, cada implementación tiene sus beneficios y restricciones.  Para aplicaciones que requieran que los usuarios se autentiquen para poder acceder a ciertos recursos, es imperativo que la sesión sea manejada de forma segura.

A medida que los ataques están creciendo dia a dia y mientras la tecnología nos permite asegurar los servidores y se implementen una buena práctica para instalar actualizaciones de software, a menudo el manejo de sesión se convierte en el eslabón más débil de la cadena. 

Mientras este documento describe la limitación de varios de los métodos de manejo de sesión, los desarrolladores deben asegurarse que un buen manejo de sesión es solo uno de los componentes para construir una aplicación segura.  El buen manejo de sesión puede ser obviado en un ataque por la implementación pobre de los componentes de la aplicación, y no debe ser visto como algo aislado.

 

Fuente: http://www.technicalinfo.net/papers/WebBasedSessionManagement.html

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