Session Management Cheat Sheet Español

AVISO

Este texto está en proceso de traducción. Para leer la versión completa (en inglés), pulse aquí.

Last revision (mm/dd/yy): 08/13/2015 Introducción al manejo de Sesiones Autentificación Web, Manejo de sesiones y Control de Acceso Una sesión Web es una secuencia de solicitudes de red HTTP y respuestas de transacción asociadas a un mismo usuario. Las aplicaciones Web modernas y complejas requieren mantener la información o el estado sobre cada usuario a lo largo de las múltiples solicitudes. Por lo tanto, las sesiones proporcionan una forma de establecer variables – como el derecho de acces y los ajustes de localización – que serán aplicadas a todas y cada una de las interacciones que el usuario tenga con la aplicación Web a lo largo de toda una sesión. Las aplicaciones web pueden crear sesiones para realizar un seguimiento de los usuarios anónimos después de la primera solicitud de éstos. Un ejemplo podría ser mantener la preferencia de idioma del usuario. Adicionalmente, las aplicaciones Web harán uso de las sesiones una vez que el usuario haya sido autentificado. Esto asegura la capacidad de identificar al usuario en cualquier solicitud posterior así como también, aplicar los controles de acceso de seguridad, el acceso autorizado a los datos privados del usuario e incrementar la usabilidad de la aplicación. Por lo tanto, las aplicaciones web actuales pueden proporcionar las capacidades de sesión, tanto pre como post autentificación. Una vez que una sesión autentificada ha sido establecida, el ID de sesión (o token) es temporalmente equivalente al método de autentificación más fuerte utilizado por la aplicación, tales como nombres de usuario y contraseña, frases de paso, contraseñas de un solo uso (OTP), certificados digitales basados en el cliente, tarjetas inteligentes o biometría (como las huellas dactilares o la retina del ojo). Ver la Guía de Referencias de OWASP sobre Autentificación. HTTP es un protocolo sin estado (RFC 2616), donde cada par de solicitud y respuesta es independiente de otras interacciones web. Por lo tanto, a fin de introducir el concepto de una sesión, se requiere poner en práctica las capacidades del manejo de sesión que vincula tanto los módulos de autentificación y del control de acceso (o autorización) comúnmente disponibles en una aplicación Web: El ID de sesión o token, enlaza las credenciales de autentificación del usuario (en la forma de una sesión de usuario) al tráfico HTTP del usuario y los controles de acceso apropiados, aplicados por la aplicación web. La complejidad de estos tres componentes (autentificación, manejador de sesiones y control de acceso) en las aplicaciones Web modernas, sumado al hecho de que su vínculo e implementación reside en las manos del desarrollador (como marco de desarrollo web no provee relaciones estrictas entre estos módulos), hace a la implementación de un módulo de manejo de sesiones seguro, un gran desafío. La divulgación, captura, predicción, fuerza bruta, o la fijación del ID de sesión dará lugar a taques de secuestro de sesión (o sidejacking), donde un atacante es capaz de hacerse pasar por un usuario víctima en la aplicación Web. Los atacantes pueden realizar dos tipos de ataques de secuestro de sesión, dirigidos o genéricos. En un ataque dirigido, el objetivo del atacante es hacerse pasar por su víctima, un usuario específico (o privilegiado) de la aplicación Web. Para los ataques genéricos, el objetivo del atacante es hacerse pasar por (o ganar acceso como) cualquier usuario válido o legítimo de la la aplicación Web. Características del ID de Sesión Para mantener el estado autentificado y hacer un seguimiento del progreso del usuario dentro de la aplicación web, éstas deben proporcionar al usuario un identificador de sesión (ID de Sesión o token) que es asignado al momento de crear la sesión y es compartido e intercambiado entre el usuario y la aplicación Web durante toda la sesión (esto es enviado en cada solicitud HTTP). El ID de sesión se compone de un par "nombre=valor". Con el objetivo de implementar ID de sesión seguros, la generación de identificadores (IDs o tokens) debe reunir las siguientes características: Huella digital del nombre del ID de Sesión El nombre utilizado por el ID de sesión no debe ser muy descriptivo ni ofrecer detalles innecesarios sobre el propósito y el significado de éste. A los nombres de ID de sesión usados por los marcos de desarrollo más comunes, tales como PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc., se les puede obtener la huella digital fácilmente. Por lo tanto, el nombre del ID de sesión puede revelar las tecnologías y los lenguajes de programación utilizados por la aplicación web. Se recomienda cambiar el nombre de ID de sesión por defecto, a un nombre genérico como "id". Longitud del ID de sesión El ID de sesión debe ser lo suficientemente largo para evitar ataques de fuerza bruta, en los que un atacante puede recorrer un rango de valores de ID y verificar la existencia de sesiones válidas. La longitud del ID de sesión debe ser de al menos 128 bit (16 bytes). OBSERVACIONES: La longitud de un ID de sesión de 128 bits se proporciona como una referencia sobre la base de las hipótesis formuladas en la siguiente sección "Entropía del ID de Sesión". Sin embargo, este número no debe ser considerado como un valor mínimo absoluto, como otros factores de implementación podrían influir en su fuerza. Por ejemplo, existen implementaciones, tales como Microsoft ASP.NET, haciendo uso de números aleatorios de 120 bits para sus identificadores de sesión (representados por cadenas de texto de 2 [10]) que pueden proporcionar una muy buena entropía efectiva y, como resultado, puede ser considerado suficientemente largo para evitar adivinar o atacar con fuerza bruta. Entropía del ID de Sesión El ID de sesión debe ser impredecible (lo suficientemente aleatorio) para prevenir ataques que intenten adivinarlos, en los que donde un atacante es capaz de adivinar o predecir el ID de una sesión válida a través de técnicas de análisis estadístico. Para este propósito, un buen Generador de Números Pseudo Aleatorios (PRNG, siglas en inglés de Pseudo Random Number Generator) debe ser usado. El valor del ID de sesión debe proporcionar al menos 64 bits de entropía (si un buen PRNG es usado, este valor se estima es la mitad de la longitud del ID de sesión). OBSERVACIONES: La entropía del ID de sesión está realmente afectada por otros factores externos que son difíciles de medir, tales como la concurrencia de sesiones activas que la aplicación Web tiene comúnmente, el tiempo de espera de caducidad absoluta de la sesión, la cantidad de intentos de adivinación de ID de sesiones por segundo, que el atacante puede hacer y que la aplicación de destino pueda soportar, etc [2]. Si un ID de sesión con una entropía de 64 bits es usada, tomará al tacante, al menos 292 años adivinar con éxito un ID de sesión válido, asumiendo que el atacante pueda intentar 10,000 adivinaciones por segundo con 100,000 sesiones simultáneas válidas en la aplicación Web[2]. Contenido (o valor) del ID de sesión El contenido (o valor) del ID de sesión debe carecer de sentido a fin de prevenir ataques de divulgación de información, en los que un atacante es capaz de decodificar el contenido del ID, extraer detalles del usuario, la sesión o del funcionamiento interno de la aplicación web. El ID de sesión debe ser, simplemente, un identificador en el lado del cliente y su valor no debe incluir información sensible (o PII). El significado y la lógica de negocios o de la aplicación asociada al ID de sesión, debe ser almacenada del lado del servido y, específicamente, en objetos de sesión o en una base de datos de gestión de sesiones o repositorio. La información almacenada puede incluir la dirección IP del cliente, el User-Agent, e-mail, nombre de usuario, ID de usuario, rol, nivel de privilegio, derechos de acceso, preferencia de idioma, ID de cuenta, estado actual, último inicio de sesión, tiempos de espera de la sesión y otros detalles internos de la sesión. Si los objetos de sesión y propiedades contienen información sensible, como números de tarjeta de crédito, es requerido cifrar y proteger debidamente el repositorio de manejo de sesiones. Autores y Editores Principales Raul Siles (DinoSec) - raul[at]dinosec.com Traducción al idioma Español: Eugenia Bahit