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 - Fallas comunes 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

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.


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