Secuestro de sesión(Session Hijacking)

Una sesión web es una secuencia de transacciones de solicitud y respuesta HTTP entre un cliente web y un servidor.

Una gran cantidad de aplicaciones web realizan un seguimiento de la información sobre cada usuario durante la duración de las transacciones web. Varias aplicaciones web tienen la capacidad de establecer variables como derechos de acceso y configuraciones de localización. Estas variables se aplican a todas y cada una de las interacciones que un usuario tiene con la aplicación web durante la sesión.

Una vez que se ha establecido una sesión autenticada, el ID de sesión (o token) es temporalmente equivalente al método de autenticación más seguro utilizado por la aplicación, como nombre de usuario y contraseña, contraseña de un solo uso, certificado digital basado en cliente, etc.

Para mantener el estado autenticado y realizar un seguimiento del progreso de los usuarios, las aplicaciones proporcionan a los usuarios un ID de sesión o token. Este token se asigna en el momento de la creación de la sesión y el usuario y la aplicación web lo comparten e intercambian durante la duración de la sesión. El ID de sesión es un par de nombre/valor.

Hay múltiples mecanismos disponibles en HTTP para mantener el estado de la sesión dentro de las aplicaciones web, como cookies (en el encabezado HTTP estándar), parámetros de URL y reescritura (definidos en RFC 3986) y argumentos de URL en solicitudes GET . Los desarrolladores de aplicaciones también utilizan argumentos corporales en las solicitudes POST . Por ejemplo, pueden utilizar campos de formulario ocultos (formularios HTML) o encabezados HTTP propietarios.

Uno de los mecanismos de intercambio de ID de sesión más utilizados son las cookies. Las cookies ofrecen capacidades avanzadas que no están disponibles con otros métodos.

Cookies de sesión.

Los nombres de ID de sesión utilizados por los marcos de desarrollo de aplicaciones web más comunes se pueden tomar fácilmente. Por ejemplo, es posible identificar fácilmente estos lenguajes y marcos de desarrollo utilizando los siguientes nombres de ID de sesión:

• PHP: PHPSESSID

• J2EE: JSESSIONID

• ColdFusion: CFID y CFTOKEN

• ASP.NET: ASP.NET_SessionId

Se recomienda cambiar el nombre de ID de sesión predeterminado del marco de desarrollo web por un nombre genérico, como id . El ID de la sesión debe ser lo suficientemente largo para evitar ataques de fuerza bruta. A veces los desarrolladores lo configuran en unos pocos bits, pero el ID de la sesión debe tener al menos 128 bits (16 bytes). Además, el ID de la sesión debe ser único e impredecible. Es una buena idea utilizar un generador de números pseudoaleatorios (PRNG) criptográficamente seguro porque el valor de ID de sesión debe proporcionar al menos 256 bits de entropía.

A veces, el ID de la sesión se incluye en la URL. Esta peligrosa práctica puede conducir a la manipulación del ID o ataques de fijación de sesión.

Los marcos de desarrollo web como ASP.NET, PHP y Ruby on Rails proporcionan sus propias funciones de gestión de sesiones y su implementación asociada.

Esto es bastante obvio, pero hay que recordar cifrar una sesión web completa con HTTPS, no sólo para el proceso de autenticación en el que se intercambian las credenciales del usuario, sino también para garantizar que la ID de la sesión se intercambie sólo a través de un canal cifrado. El uso de un canal de comunicación cifrado también protege la sesión contra algunos ataques de fijación de sesión, en los que el atacante puede interceptar y manipular el tráfico web para inyectar (o arreglar) la ID de la sesión en el navegador web de la víctima.

Hay dos tipos de cookies: cookies no persistentes (o de sesión) y cookies persistentes. Si una cookie tiene un atributo Max-Age o Expires , se considera una cookie persistente y el navegador web la almacena en el disco hasta el momento de su vencimiento.

La configuración de una cookie con el indicador HTTPOnly obliga al navegador web a que esta cookie sea procesada únicamente por el servidor, y cualquier intento de acceder a la cookie desde código o scripts basados ​​en el cliente está estrictamente prohibido. Esto protege contra varios tipos de ataques, incluido CSRF.

Hay varias formas en que un atacante puede secuestrar una sesión y varias formas en que un token de sesión puede verse comprometido:

• Predicción de tokens de sesión: por eso es importante utilizar tokens no predecibles, como se analizó anteriormente en esta sección.

• Rastreo de sesiones: esto puede ocurrir mediante la recopilación de paquetes de sesiones web no cifradas.

• Ataque en la ruta (anteriormente conocido como ataque man-in-the-middle): en este tipo de ataque, el atacante se ubica en la ruta entre el cliente y el servidor web. Además, un navegador (o una extensión o un complemento) puede verse comprometido y utilizarse para interceptar y manipular sesiones web entre el usuario y el servidor web. Este ataque basado en navegador se conocía anteriormente como ataque de hombre en el navegador.

Si las aplicaciones web no validan y filtran los valores de ID de sesión no válidos, pueden usarse potencialmente para explotar otras vulnerabilidades web, como la inyección SQL (si los ID de sesión se almacenan en una base de datos relacional) o XSS persistente (si los ID de sesión se almacenan en una base de datos relacional). almacenado y reflejado posteriormente por la aplicación web).