Métodos Alternativos para Establecer Sesiones en Aplicaciones Web

  • Posted on: 6 July 2015
  • By: ReYDeS

Para implementar diversas funcionalidades en las aplicaciones web se necesita utilizar el concepto de una sesión. En el caso del registro o registro de ingreso (login) hacia una aplicación web, su inexistencia requeriría al usuario reingresar las credenciales de acceso para cada página de la aplicación web. Por lo tanto, después de la autenticación del usuario una única vez, la aplicación crea una sesión para este y trata todas las peticiones correspondientes a la sesión como provenientes desde el usuario.

La manera más sencilla de implementar sesiones es entregar a cada usuario un token o identificador único de sesión. Luego en cada petición subsecuente hacia la aplicación, el usuario enviará nuevamente este token, permitiendo a la aplicación determinar con cuales secuencias de peticiones anteriores se relaciona la petición actual.

No todas las aplicaciones web utilizan sesiones, frecuentemente se encontrarán dos alternativas posibles.

Autenticación HTTP

Las Aplicaciones Web utilizan diversas tecnologías basadas en la autenticación HTTP (Basic, digest, NTLM), las cuales evitan la necesidad de utilizar sesiones. Con la autenticación HTTP, el componente del cliente interactúa directamente con el mecanismo de autenticación mediante el navegador web utilizando las cabeceras HTTP, y no mediante un código específico de la aplicación contenido dentro de cada página individual.

Después de ingresadas las credenciales en el recuadro de diálogo del navegador web, el navegador envía nuevamente estas credenciales con cada petición subsecuente hacia el mismo servidor. Esto es equivalente a una aplicación utilizando una autenticación basada en un formulario HTML y colocar el formulario de login en cada página de la aplicación, requiriendo a los usuarios volver a autenticarse a si mismos con cada acción realizada.

Por lo tanto, cuando una autenticación HTTP es utilizada, es posible para una aplicación web volver a identificar al usuario entre diversas peticiones sin utilizar sesiones. Sin embargo, la autenticación HTTP raramente es utilizada en aplicaciones en Internet.

Para las siguientes demostraciones se utiliza Zed Attack Proxy configurado con Firefox.

Se ingresa a una Aplicación Web la cual utiliza una Autenticación Básica.

Se visualiza la respuesta devuelta desde la Aplicación Web. La cual indica al navegador web a presentar un recuadro de diálogo solicitando credenciales de acceso válidas.

Se ingresan las credenciales correctas. Anotar el campo “Authorization:” donde se incluye la contraseña codificada en Base64.

Ahora se procede a ingresar a una Aplicación Web utilizando la Autenticación “Digest”.

En la respuesta devuelta por la aplicación web anotar el campo “WWW-Authenticate:”

Ingresadas las credenciales correctas, se visualiza los datos enviados hacia la Aplicación Web. En este tipo de autenticación no se envían las credenciales codificadas o cifradas directamente.

Estados sin Sesión

Algunas aplicaciones no entregan tokens de sesión para gestionar el estado de la interacción del usuario con la aplicación web. En lugar de esto transmiten todos los datos requeridos para gestionar el estado mediante el cliente, usualmente en una cookie o un campo oculto de formulario. Este mecanismo utiliza un estado sin sesión como el ViewState de ASP.NET lo hace.

Para asegurar este tipo de mecanismo, los datos transmitidos mediante el cliente deben ser adecuadamente protegidos. Esto implica construir agrupaciones binarias conteniendo toda la información del estado y cifrando o firmando esto utilizando un algoritmo reconocido. Se debe incluir suficiente contexto dentro de los datos para prevenir por parte de un atacante la recolección de un objeto de estado en una ubicación dentro de la aplicación web y enviarlo nuevamente hacia otra ubicación para causar un comportamiento indeseable.

Para la siguiente demostración se utilizará la Aplicación Web de nombre WebGoat.NET incluida dentro de OWASP Broken Web Applications Project.

Anotar el campo de nombre “__VIEWSTATE” incluido dentro del cuerpo devuelto en la respuesta de la Aplicación Web.

La decodificación del "ViewState" se puede realizar utilizando Python. Entre los datos decodificados se puede observar también un texto “Session” y el mismo valor contenido en la Cookie de nombre “ASP.NET_SessionId”.

Fuentes:

http://tools.ietf.org/html/rfc2617
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
http://test.webdav.org/
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
https://docs.python.org/2/library/base64.html

Sobre el Autor


Alonso Eduardo Caballero Quezada - ReYDeS
Instructor y Consultor Independiente en Ciberseguridad
Correo Electrónico: ReYDeS@gmail.com
Twitter: https://twitter.com/Alonso_ReYDeS
LinkedIn: https://pe.linkedin.com/in/alonsocaballeroquezada/
Facebook: https://www.facebook.com/alonsoreydes
Youtube: https://www.youtube.com/c/AlonsoCaballero


Suscribete