Administración de sesiones en aplicaciones Web


Muchos de los programas que utilizamos hoy en día requieren autenticar a los usuarios antes de permitirles el acceso a información sensible; tradicionalmente, la forma de reconocer los privilegios de acceso ha sido mediante el establecimiento de sesiones de usuario, pero el aumento exponencial de aplicaciones basadas en protocolo HTTP, así como de amenazas a la seguridad, han hecho que surjan nuevos requerimientos que deben ser atendidos de forma inmediata por las organizaciones.





Saber quién está haciendo qué, es uno de los principios de la seguridad informática moderna; es por eso que muchas de las aplicaciones que usamos regularmente requieren la autenticación de sus usuarios antes de permitirles el acceso a cierta información o a cierto conjunto de transacciones. La forma habitual de llevar a cabo esta tarea de certificación del usuario es el establecimiento de una “sesión” la cual normalmente se mantiene vigente desde que el usuario presenta sus credenciales (password, certificado digital, etc.) hasta que este cierra el enlace o la actividad cesa por un período de tiempo prolongado.

Para mantener niveles de seguridad capaces de afrontar los peligros del mundo virtual, es necesario que durante la fase de diseño de un ambiente Web seguro, se revisen los procedimientos y políticas de seguridad de las corporaciones, junto con la infraestructura sobre la cual será implantado el servicio.

(Ver Figura N° 1). De esta forma se apreciará la seguridad como un todo coherente que no depende únicamente de los mecanismos de acceso, sino de todo el entorno que apoya el servicio Web.

figura 1

 

Figura N°1. Esquema de diseño seguro de un ambiente Web

En el caso de aplicaciones que son accesibles a través de navegadores de Internet, la naturaleza del protocolo sobre el cual se transmite la información (HTTP - HyperText Transfer Protocol) genera requerimientos particulares que deben ser atendidos para garantizar la seguridad del activo más preciado de estos tiempos, la información. En líneas generales podemos decir que el protocolo HTTP es atómico, esto quiere decir que cada solicitud que se realiza desde el navegador hasta el servidor es procesada de forma totalmente independiente con respecto a solicitudes previas o posteriores, de tal manera el protocolo no conoce, ni soporta, el concepto de “sesión” al que hemos hecho referencia.

Una alternativa que podría considerarse viable, es el envío de las credenciales del usuario con cada solicitud o transacción; en otras palabras, “disolver” la sesión del usuario en un conjunto de interacciones unitarias con el servidor, autenticando cada una de ellas. Si bien esta alternativa puede funcionar, representa mayor complejidad para los clientes, pérdida de desempeño del portal y en líneas generales una mala experiencia para el usuario; todas situaciones inaceptables, especialmente dentro de ambientes exigentes como el comercio electrónico, donde típicamente se busca reducir costos e incrementar la utilización por parte de los clientes.

Ante el dilema “seguridad vs. desempeño” se buscó la forma de implementar una política similar a la anteriormente descrita, pero que fuese totalmente transparente para el usuario, quien es en definitiva el que ingresa a la aplicación, interactúa con ella y realiza sus operaciones dentro de una “única sesión”.

La forma de implementación será entonces:

1) El usuario envía al sitio sus credenciales.
2) El sitio verifica dichas credenciales.
3) Confirmada la identidad, el sitio envía al navegador del cliente un “ticket”.
4) El navegador envía al servidor dicho “ticket” con cada solicitud posterior.

De este modo el “ticket” identifica a la sesión y, a los efectos del servidor, cualquier solicitud que lo incluya pertenece a la misma y está aprobada por las credenciales del usuario que ya fueron verificadas.

Prácticamente todos los paquetes y lenguajes de programación utilizados para el desarrollo de aplicaciones en Internet incluyen herramientas que automatizan este proceso. El “ticket” es enviado en la forma de un cookie, que no es otra cosa que un pequeño paquete de datos que el navegador envía automáticamente junto con sus solicitudes a determinado dominio.

En este punto es importante puntualizar lo siguiente: la tenencia del “ticket” es lo que identifica a una sesión (y por extensión al usuario que inició la misma). En otras palabras, cualquier solicitud que incluya el mismo será completamente equivalente a una solicitud válida y la misma será ejecutada por el servidor.

Como se deriva de lo planteado en el párrafo anterior, la protección de este “ticket” es fundamental para garantizar que solamente el usuario que inició la sesión (en particular, su navegador) tenga acceso al mismo. Para analizar los requerimientos de seguridad, se pueden considerar tres etapas dentro de la vida del “ticket”:

a) generación y envío al usuario.
b) utilización.
c) expiración.

Generación y envío al usuario

En primer lugar es crítico que el contenido del “ticket” no sea previsible, para lo cual la mejor solución es elegir un valor al azar. Si el “ticket” se confeccionara de algún modo variable pero sencillo de predecir (por ejemplo nombre de usuario concatenado con la fecha de establecimiento de la sesión), entonces un atacante simplemente podría crear un ticket con el mismo mecanismo y robar (“hijack”) la sesión del usuario oficial.

En segundo lugar, el valor al azar elegido debe ser suficientemente grande como
para evitar ataques de fuerza bruta. Si el valor al azar fuera un número de 0 a 9999, por ejemplo, un atacante podría empezar a mandar solicitudes con valores sucesivos hasta determinar el correcto (lo cual le llevaría 5000 intentos en promedio, algo que posiblemente pueda realizar en segundos con los equipos informáticos y los canales de comunicación actuales). En el pasado, un error común en el desarrollo de portales e incluso en las herramientas de desarrollo era la posibilidad de “predecir” el próximo identificador de sesión con base en uno emitido previamente.

Finalmente, luego de elegido un valor al azar suficientemente grande, el mismo debe enviarse al navegador del cliente para que el mismo pueda “devolverlo” con cada transacción. Dado que todos los datos viajan en claro en el protocolo HTTP, cualquier atacante con acceso a un nodo intermedio o a la red de comunicaciones local del cliente o del servidor podría obtener el valor en tránsito. Esto se evita mediante la utilización de técnicas criptográficas, siendo la más usual el estándar SSL (Secure Sockets Layer).

Utilización

Cuando el cliente recibe el valor que identifica la sesión, el mismo será guardado por el navegador para su posterior envío con cada solicitud. Es importante que el servidor marque el cookie que contenga el identificador como de tipo “session”.

Esto asegura que el mismo solamente será mantenido en memoria y no se grabará al archivo de cookies del navegador, lo cual protege al usuario de alguien con acceso a su filesystem (por ejemplo un administrador de red o un usuario remoto con derechos sobre su equipo).

Al igual que en el punto anterior, dado que el identificador viajará con cada solicitud, toda la comunicación deberá protegerse con un túnel de SSL o algún mecanismo equivalente. De otro modo, se podría obtener el cookie en tránsito e introducir transacciones o solicitudes no autorizadas.

Finalmente, y como un control adicional, es relevante que el servidor no utilice solamente el cookie para identificar la sesión, sino la combinación del mismo con la dirección IP del cliente. De este modo, aunque el identificador de sesión se descubierto por un atacante remoto (por ejemplo logrando que el cliente entre a un sitio controlado por él mediante una debilidad de “Cross Site Scripting”), a menos que dicho atacante logre también establecer una conexión con la IP del usuario autorizado no podrá ingresar solicitudes o transacciones dentro de la sesión.

Expiración

Cuando el cliente establece su intención de finalizar la sesión, inmediatamente el identificador de la misma debe ser marcado como inválido por el servidor.

Toda transacción posterior que incluya el mismo debe ser ignorada y a la vez debe asegurarse que el valor utilizado no sea reutilizado. Adicionalmente, el servidor debe incluir un tiempo de inactividad pasado el cual la sesión expira automáticamente, de modo de evitar que el usuario deje su navegador abierto (por error u omisión) y un atacante pueda acceder al mismo.

Conclusiones

La correcta administración de sesiones es un aspecto crítico para garantizar la seguridad de una aplicación accesible por Internet. Si bien en muchos casos los propios lenguajes de programación ofrecen facilidades para resolver el tema, debe prestarse especial atención al mismo tanto durante el desarrollo, como durante las pruebas.

Como una simple guía de aspectos a recordar puede citarse:

> Utilizar identificadores de sesión elegidos al azar y del largo adecuado
> Proteger todas las sesiones que permiten acceder a información privada o a transacciones que requieran autorización mediante SSL
> No reutilizar identificadores de sesión
> Expirar las sesiones por inactividad
> Probar la administración de sesiones (y el intento de violación de las mismas) antes de la puesta en producción de cualquier aplicación en Internet
> Considerar las mejores prácticas para el diseño seguro de un servicio Web, como se presenta en la Figura Nº 2:

Figura 2

Figura N° 2. Consideraciones para el diseño seguro de un servicio Web

Espiñeira, Sheldon y Asociados, Firma miembro de PricewaterhouseCoopers

Fuente:
pc-news.com



Otras noticias de interés:

La controversial LSSI deberá cambiarse dentro de un año.
El site Periodistadigital.com, ha puesto en marcha una campaña de recogida de apoyos para recurrir la polémica LSSI ante el defensor del pueblo, una ley que por otro lado deberá ser revisada obligatoriamente dentro de un año. Periodistadigital....
Nuevo troyano para Android genera costes extra
Inteco ha alertado sobre Kituri, un nuevo troyano para Android capaz de enviar mensajes SMS sin autorización. El troyano se camufla bajo la imagen de un juego de rol y es capaz de alterar la configuración de conexión del dispositivo, generando cos...
Bug que permitía borrar las fotos de Facebook de los perfiles de otros usuarios
Recientemente, un experto informático llamado Laxman Muthiyah ha descubierto una vulnerabilidad en Facebook que podría haber causado graves problemas a la compañía....
PAPIRUX La Revista Libre de Software Libre
La gente de Papitux ya van por su 2da revista, en la 1era hablan de: La nueva cara de la GPL - Las bondades del software libre frente al software privativo. - Juego: Circus Linux! - How To: Instalar Ubuntu 8.04 conservando Windows XP - Tip’s y tru...
Revista Digital El Derecho Informático Nº 9
elderechoinformatico.com ha liberado su número 9 de su interesante revista digital con los siguientes temas:...
Debilidad en autenticación de Mozilla y Firefox
Los mecanismos de autenticación en el protocolo HTTP, están definidos en el documento RFC 2617 del IETF (The Internet Engineering Task Force). Allí se establece que se deben utilizar mecanismos de desafío-respuesta, intercambiándose varias solic...
Dos nuevas vulnerabilidades en servidores Oracle
Se han descubierto dos nuevas vulnerabilidades de desbordamiento de búfer en productos de Oracle. Ambos problemas pueden considerarse de gravedad al permitir a un atacante tomar el control total de la máquina afectada....
IE 10 contará con Do Not Track activado por defecto
La gigante informática de la ciudad de Redmond ha anunciado que la próxima versión de su popular navegador por internet, Internet Explorer 10, contará con una gran novedad que todos los usuarios agradecerán, en especial aquellos que les preocupa...
Nueva versión de Fedora, esta vez la 13
Es una distribución Linux para propósitos generales basada en RPM, que se mantiene gracias a una comunidad internacional de ingenieros, diseñadores gráficos y usuarios que informan de fallos y prueban nuevas tecnologías. Cuenta con el respaldo y...
Chrome arregla dos fallos de seguridad graves
Google soluciona dos vulnerabilidades graves en la versión estable de Chrome, que pueden hacer que un usuario malicioso tome el control del ordenador afectado....

Brindanos
un o una


Redes Sociales

Publicidad


Gana Bitcoins desde tu casa

Categorías


Planeta Vaslibre

Blog Roll




Nube de tags

  • administracion
  • anonimato
  • anonimo
  • antivirus
  • apache
  • aplicaciones
  • blog
  • bsd
  • bug
  • centos
  • chrome
  • cifrado
  • computer
  • debian
  • exploits
  • fedora
  • fice
  • firefox
  • forense
  • freebsd
  • gentoo
  • github
  • gnome
  • gnu
  • gpl
  • gtk
  • hack
  • hacking
  • hosting
  • informatica
  • internet
  • isos
  • libre
  • licencias
  • linux
  • linuxmint
  • lxde
  • micros
  • mint
  • mit
  • mozilla
  • mysql
  • noticia
  • opensource
  • pgp
  • php
  • sabayon
  • seguridad
  • sesiones
  • system
  • tecnologia
  • thunar
  • thunderbird
  • tor
  • troyanos
  • tware
  • ubuntu
  • underground
  • vaslibre
  • virus
  • viserproject
  • vivaldi
  • vulnerabilidades
  • web
  • website
  • windows
  • xanadu
  • xfce
  • xombra