Introducción

Autenticación web, gestión de sesiones y control de acceso :

Una sesión web es una secuencia de transacciones HTTP de solicitud y

respuesta de red asociadas al mismo usuario. Las aplicaciones web modernas
y complejas requieren la retención de información o estado sobre cada usuario
durante la duración de múltiples solicitudes. Por lo tanto, las sesiones
proporcionan la capacidad de establecer variables, como los derechos de
acceso y la configuración de localización, que se aplicarán a todas y cada una
de las interacciones que un usuario tenga con la aplicación web durante la
sesión.

Las aplicaciones web pueden crear sesiones para realizar un seguimiento de

los usuarios anónimos después de la primera solicitud del usuario. Un ejemplo
sería mantener la preferencia de idioma del usuario. Además, las aplicaciones
web utilizarán sesiones una vez que el usuario se haya autenticado. Esto
garantiza la capacidad de identificar al usuario en cualquier solicitud posterior,
así como poder aplicar controles de acceso de seguridad, acceso autorizado
a los datos privados del usuario y aumentar la usabilidad de la aplicación. Por
lo tanto, las aplicaciones web actuales pueden proporcionar capacidades de
sesión tanto de autenticación previa como posterior.

Una vez que se ha establecido una sesión autenticada, la ID de sesión (o

token) es temporalmente equivalente al método de autenticación más fuerte
utilizado por la aplicación, como nombre de usuario y contraseña, frases de
contraseña, contraseñas de un solo uso (OTP), certificados digitales basados
en el cliente, tarjetas inteligentes o datos biométricos (como huellas dactilares
o retina ocular).

HTTP es un protocolo sin estado ( RFC2616 sección 5), donde cada par de
solicitud y respuesta es independiente de otras interacciones web. Por lo tanto,
para introducir el concepto de sesión, es necesario implementar capacidades
de administración de sesión que vinculen tanto los módulos de autenticación
como de control de acceso (o autorización) comúnmente disponibles en
aplicaciones web:

El identificador de sesión o el token enlaza las credenciales de autenticación

del usuario (en forma de sesión de usuario) al tráfico HTTP del usuario y los
controles de acceso apropiados impuestos por la aplicación web. La
complejidad de estos tres componentes (autenticación, gestión de sesión y
control de acceso) en aplicaciones web modernas, más el hecho de que su
implementación y enlace reside en las manos del desarrollador web (ya que el
marco de desarrollo web no proporciona relaciones estrictas entre estos
módulos), hace que la implementación de un módulo de administración de
sesión segura sea muy desafiante.

La divulgación, captura, predicción, fuerza bruta o fijación de la ID de la sesión

conducirá a ataques de secuestro de sesión (o secuestro lateral), donde un
atacante puede suplantar por completo a 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 un usuario víctima específico (o privilegiado) de la
aplicación web. Para los ataques genéricos, el objetivo del atacante es
suplantar (u obtener acceso como) cualquier usuario válido o legítimo en la
aplicación web.

Propiedades de ID de sesión
Para mantener el estado autenticado y rastrear el progreso de los usuarios
dentro de la aplicación web, las aplicaciones proporcionan a los usuarios
un identificador de sesión (ID de sesión o token) que se asigna en el
momento de la creación de la sesión, y que el usuario y la aplicación web
comparten e intercambian. durante la sesión (se envía en cada solicitud
HTTP). La ID de sesión es un name=valuepar.
Con el objetivo de implementar ID de sesión segura, la generación de
identificadores (ID o tokens) debe cumplir con las siguientes propiedades.

Nombre de ID de sesión Huellas digitales

El nombre utilizado por la ID de la sesión no debe ser extremadamente
descriptivo ni ofrecer detalles innecesarios sobre el propósito y el significado
de la ID.

Los nombres de ID de sesión utilizados por los marcos de desarrollo de

aplicaciones web más comunes se pueden identificar fácilmente ,
como PHPSESSID(PHP), JSESSIONID(J2EE) CFIDy CFTOKEN(ColdFusion), ASP.NET_S
essionId(ASP .NET), etc. Por lo tanto, el nombre de ID de sesión puede revelar
tecnologías y lenguajes de programación utilizados por la aplicación web.
Se recomienda cambiar el nombre de ID de sesión predeterminado del marco
de desarrollo web a un nombre genérico, como id.

Longitud de ID de sesión
La ID de la sesión debe ser lo suficientemente larga como para evitar ataques
de fuerza bruta, donde un atacante puede recorrer todo el rango de valores de
ID y verificar la existencia de sesiones válidas.

La longitud del ID de la sesión debe ser al menos 128 bits (16 bytes).
NOTA :
 La longitud de ID de sesión de 128 bits se proporciona como referencia en función de
los supuestos hechos en la siguiente sección Entropía de ID de sesión . Sin embargo,
este número no debe considerarse como un valor mínimo absoluto, ya que otros
factores de implementación pueden influir en su solidez.
 Por ejemplo, hay implementaciones bien conocidas, como los identificadores de
sesión de Microsoft ASP.NET : " El identificador de sesión de ASP .NET es un número
generado aleatoriamente codificado en una cadena de 24 caracteres que consiste en
caracteres en minúscula de la a a la z y números del 0 a 5 ".
 Puede proporcionar una entropía efectiva muy buena y, como resultado, puede
considerarse el tiempo suficiente para evitar adivinanzas o ataques de fuerza bruta.

Entropía de ID de sesión
El ID de la sesión debe ser impredecible (lo suficientemente aleatorio) para
evitar ataques de adivinanzas, donde un atacante puede 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, se debe utilizar un buen PRNG (generador de números
pseudoaleatorios).
El valor de ID de sesión debe proporcionar al menos una 64 bitsentropía (si
se utiliza un buen PRNG, se estima que este valor es la mitad de la longitud
de la ID de sesión).
NOTA :

 La entropía de ID de sesión se ve realmente afectada por otros factores externos y

difíciles de medir, como el número de sesiones activas concurrentes que tiene
comúnmente la aplicación web, el tiempo de espera de caducidad de sesión absoluto,
la cantidad de conjeturas de ID de sesión por segundo que puede hacer el atacante
y la aplicación web de destino puede soportar, etc.
 Si 64 bitsse usa una ID de sesión con una entropía de , un atacante tardará al menos
292 años en adivinar con éxito una ID de sesión válida, suponiendo que el atacante
pueda intentar 10,000 conjeturas por segundo con 100,000 sesiones simultáneas
válidas disponibles en la aplicación web.
 Más información aquí .

Contenido de ID de sesión (o valor)

El contenido (o valor) de la ID de sesión no debe tener sentido para evitar
ataques de divulgación de información, donde un atacante puede decodificar
el contenido de la ID y extraer detalles del usuario, la sesión o el
funcionamiento interno de la aplicación web.

La ID de sesión debe ser simplemente un identificador en el lado del cliente, y

su valor nunca debe incluir información confidencial (o PII ).

El significado y la lógica comercial o de aplicación asociada a la ID de sesión

deben almacenarse en el lado del servidor, y específicamente, en objetos de
sesión o en una base de datos o repositorio de administración de sesión.

La información almacenada puede incluir la dirección IP del cliente, Agente de

usuario, correo electrónico, nombre de usuario, ID de usuario, rol, nivel de
privilegio, derechos de acceso, preferencias de idioma, ID de cuenta, estado
actual, último inicio de sesión, tiempos de espera de sesión y otra sesión
interna detalles. Si los objetos y propiedades de la sesión contienen
información confidencial, como números de tarjetas de crédito, es necesario
encriptar y proteger debidamente el repositorio de administración de la sesión.

Se recomienda crear ID de sesión criptográficamente fuertes mediante el uso

de funciones hash criptográficas como SHA256.

Implementación de gestión de
sesiones
La implementación de gestión de sesión define el mecanismo de intercambio
que se utilizará entre el usuario y la aplicación web para compartir e
intercambiar continuamente la ID de sesión. Existen múltiples mecanismos
disponibles en HTTP para mantener el estado de la sesión dentro de las
aplicaciones web, como cookies (encabezado HTTP estándar), parámetros de
URL (reescritura de URL - RFC2396 ), argumentos de URL en solicitudes
GET, argumentos del cuerpo en solicitudes POST, como campos de formulario
ocultos (Formularios HTML) o encabezados HTTP propietarios.

El mecanismo de intercambio de ID de sesión preferido debe permitir definir

propiedades avanzadas de token, como la fecha y hora de vencimiento del
token, o restricciones de uso granulares. Esta es una de las razones por las
cuales las cookies (RFC 2109 y 2965 y 6265 ) son uno de los mecanismos de
intercambio de ID de sesión más utilizados, ya que ofrecen capacidades
avanzadas que no están disponibles en otros métodos.

El uso de mecanismos específicos de intercambio de ID de sesión, como

aquellos en los que la ID está incluida en la URL, puede revelar la ID de sesión
(en enlaces y registros web, historial y marcadores del navegador web, el
encabezado Referer o los motores de búsqueda), así como facilitar otros
ataques, como la manipulación de la identificación o los ataques de fijación de
sesión .

Implementaciones de gestión de sesión

incorporadas
Los marcos de desarrollo web, como J2EE, ASP .NET, PHP y otros, brindan
sus propias funciones de administración de sesión e implementación
asociada. Se recomienda usar estos marcos integrados en lugar de construir
uno hecho en casa desde cero, ya que se usan en todo el mundo en múltiples
entornos web y han sido probados por las comunidades de seguridad y
desarrollo de aplicaciones web a lo largo del tiempo.

Sin embargo, tenga en cuenta que estos marcos también han presentado
vulnerabilidades y debilidades en el pasado, por lo que siempre se recomienda
utilizar la última versión disponible, que potencialmente corrige todas las
vulnerabilidades conocidas, así como revisar y cambiar la configuración
predeterminada para mejorar su seguridad siguiendo las recomendaciones
descritas a lo largo de este documento.

Las capacidades de almacenamiento o el depósito utilizado por el mecanismo

de administración de la sesión para guardar temporalmente las ID de la sesión
deben ser seguras, protegiendo las ID de la sesión contra la divulgación
accidental local o remota o el acceso no autorizado.

Mecanismos de intercambio de ID de
sesión usados versus aceptados
Una aplicación web debe hacer uso de cookies para la gestión del intercambio
de ID de sesión. Si un usuario envía un ID de sesión a través de un mecanismo
de intercambio diferente, como un parámetro de URL, la aplicación web debe
evitar aceptarlo como parte de una estrategia defensiva para detener la fijación
de la sesión.

NOTA :

 Incluso si una aplicación web utiliza cookies como su mecanismo predeterminado

de intercambio de ID de sesión, también podría aceptar otros mecanismos de
intercambio.
 Por lo tanto, es necesario confirmar a través de pruebas exhaustivas todos los
diferentes mecanismos actualmente aceptados por la aplicación web al procesar
y administrar las ID de sesión, y limitar los mecanismos de seguimiento de ID de
sesión aceptados a solo cookies.
 En el pasado, algunas aplicaciones web usaban parámetros de URL, o incluso
cambiaban de cookies a parámetros de URL (mediante reescritura automática de
URL), si se cumplen ciertas condiciones (por ejemplo, la identificación de clientes
web sin soporte para cookies o no aceptar cookies debido a preocupaciones de
privacidad del usuario).

Transport Layer Security

Para proteger el intercambio de ID de sesión del espionaje activo y la
divulgación pasiva en el tráfico de la red, es esencial usar una conexión HTTPS
encriptada (TLS) para toda la sesión web, no solo para el proceso de
autenticación donde se intercambian las credenciales del usuario.

Además, el Secure atributo de cookie debe usarse para garantizar que la ID de

la sesión solo se intercambie a través de un canal encriptado. El uso de un
canal de comunicación encriptado 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 sesión en el
navegador web de la víctima (ver aquí y aquí ).
El siguiente conjunto de mejores prácticas se enfoca en proteger la ID de
sesión (específicamente cuando se usan cookies) y ayudar con la integración
de HTTPS dentro de la aplicación web:
 No cambie una sesión determinada de HTTP a HTTPS, o viceversa, ya que esto
revelará la ID de la sesión de forma clara a través de la red.
o Al redirigir a HTTPS, asegúrese de que la cookie esté configurada o
regenerada después de que se haya producido la redirección.
 No mezcle contenidos cifrados y no cifrados (páginas HTML, imágenes, CSS,
archivos JavaScript, etc.) en la misma página o desde el mismo dominio.
 Siempre que sea posible, evite ofrecer contenidos públicos no encriptados y
contenidos privados encriptados desde el mismo host. Cuando se requiera
contenido inseguro, considere alojarlo en un dominio inseguro separado.
 Implemente HTTP Strict Transport Security (HSTS) para hacer cumplir las
conexiones HTTPS.

Es importante enfatizar que TLS no protege contra la predicción de ID de

sesión, la fuerza bruta, la manipulación o fijación del lado del cliente; sin
embargo, proporciona protección efectiva contra un atacante que intercepta o
roba ID de sesión a través de un hombre en el medio ataque.

Galletas
El mecanismo de intercambio de ID de sesión basado en cookies proporciona
múltiples características de seguridad en forma de atributos de cookies que
pueden usarse para proteger el intercambio de la ID de sesión:

Atributo seguro
El Secureatributo cookie indica a los navegadores web que solo envíen la
cookie a través de una conexión cifrada HTTPS (SSL / TLS). Este mecanismo
de protección de sesión es obligatorio para evitar la divulgación de la ID de
sesión a través de ataques MitM (Man-in-the-Middle). Asegura que un atacante
no pueda simplemente capturar la ID de sesión del tráfico del navegador web.
Obligar a la aplicación web a usar solo HTTPS para su comunicación (incluso
cuando el puerto TCP / 80, HTTP, está cerrado en el host de la aplicación web)
no protege contra la divulgación de ID de sesión si la Securecookie no se ha
configurado; el navegador web puede ser engañado para revelar la ID de
sesión a través de una conexión HTTP sin cifrar. El atacante puede interceptar
y manipular el tráfico de usuarios de la víctima e inyectar una referencia HTTP
sin cifrar a la aplicación web que obligará al navegador web a enviar la ID de
la sesión de forma clara.

Atributo HttpOnly
El HttpOnlyatributo de cookie indica a los navegadores web que no deben
permitir que los scripts (por ejemplo, JavaScript o VBscript) tengan acceso a
las cookies a través del objeto DOM document.cookie. Esta protección de ID
de sesión es obligatoria para evitar el robo de ID de sesión a través de ataques
XSS.

Atributo SameSite
SameSite permite que un servidor defina un atributo de cookie, lo que hace
imposible que el navegador envíe esta cookie junto con las solicitudes entre
sitios. El objetivo principal es mitigar el riesgo de fuga de información de origen
cruzado, y proporciona cierta protección contra ataques de falsificación de
solicitudes entre sitios.

Atributos de dominio y ruta

El Domainatributo cookie indica a los navegadores web que solo envíen la
cookie al dominio especificado y a todos los subdominios. Si no se establece
el atributo, de manera predeterminada, la cookie solo se enviará al servidor de
origen. El Pathatributo cookie indica a los navegadores web que solo envíen la
cookie al directorio o subdirectorios especificados (o rutas o recursos) dentro
de la aplicación web. Si no se establece el atributo, de manera
predeterminada, la cookie solo se enviará para el directorio (o ruta) del recurso
solicitado y la configuración de la cookie.
Se recomienda utilizar un ámbito restringido o restringido para estos dos
atributos. De esta manera, el Domainatributo no debe establecerse
(restringiendo la cookie solo al servidor de origen) y el Pathatributo debe
establecerse lo más restrictivo posible a la ruta de la aplicación web que utiliza
la ID de sesión.
Establecer el Domainatributo en un valor demasiado permisivo,
como example.compermitir que un atacante inicie ataques a las ID de sesión
entre diferentes hosts y aplicaciones web que pertenecen al mismo dominio,
conocidas como cookies de subdominio cruzado. Por ejemplo, las
vulnerabilidades en www.example.compodrían permitir a un atacante obtener
acceso a las ID de sesión desde secure.example.com.
Además, se recomienda no mezclar aplicaciones web de diferentes niveles de
seguridad en el mismo dominio. Las vulnerabilidades en una de las
aplicaciones web permitirían a un atacante establecer la ID de sesión para una
aplicación web diferente en el mismo dominio mediante el uso de
un Domainatributo permisivo (como example.com), que es una técnica que se
puede usar en ataques de fijación de sesión .
Aunque el Pathatributo permite el aislamiento de ID de sesión entre diferentes
aplicaciones web que utilizan diferentes rutas en el mismo host, se recomienda
no ejecutar diferentes aplicaciones web (especialmente desde diferentes
niveles de seguridad o ámbitos) en el mismo host. Estas aplicaciones pueden
utilizar otros métodos para acceder a los ID de sesión, como
el document.cookieobjeto. Además, cualquier aplicación web puede establecer
cookies para cualquier ruta en ese host.
Las cookies son vulnerables a los ataques de suplantación / secuestro /
envenenamiento de DNS, donde un atacante puede manipular la resolución de
DNS para obligar al navegador web a revelar la ID de sesión para un host o
dominio determinado.

Caducar y atributos de edad máxima

Los mecanismos de gestión de sesión basados en cookies pueden utilizar dos
tipos de cookies, cookies no persistentes (o de sesión) y cookies
persistentes. Si una cookie presenta el Max-Age(que tiene preferencia
sobre Expires) o los Expiresatributos, se considerará una cookie persistente y
el navegador web la almacenará en el disco hasta el momento de vencimiento.
Por lo general, las capacidades de administración de sesión para rastrear a
los usuarios después de la autenticación hacen uso de cookies no
persistentes. Esto obliga a que la sesión desaparezca del cliente si se cierra
la instancia actual del navegador web. Por lo tanto, se recomienda
encarecidamente utilizar cookies no persistentes para fines de administración
de la sesión, de modo que la ID de la sesión no permanezca en la memoria
caché del cliente web durante largos períodos de tiempo, desde donde un
atacante puede obtenerla.

 Asegúrese de que la información confidencial no esté comprendida,

asegurándose de que la información confidencial no sea persistente / cifrada /
almacenada según sea necesario mientras dure la necesidad
 Asegúrese de que las actividades no autorizadas no puedan realizarse mediante
la manipulación de cookies
 Asegúrese de que el indicador de seguridad esté configurado para evitar la
transmisión accidental por "el cable" de una manera no segura
 Determine si todas las transiciones de estado en el código de la aplicación
verifican correctamente las cookies y hacen cumplir su uso
 Asegúrese de que toda la cookie debe estar encriptada si persisten datos
confidenciales en la cookie
 Defina todas las cookies que utiliza la aplicación, su nombre y por qué son
necesarias

API de almacenamiento web HTML5

El Grupo de trabajo de tecnología de aplicación de hipertexto web (WHATWG)
describe las API de almacenamiento web
HTML5 localStoragey sessionStorage, como mecanismos para almacenar
pares de nombre-valor del lado del cliente. A diferencia de las cookies HTTP,
el contenido de localStorage y sessionStorageno se comparte automáticamente
dentro de las solicitudes o respuestas del navegador y se utiliza para
almacenar datos del lado del cliente.

La API localStorage
Alcance
localStorage Se puede acceder a los datos almacenados utilizando la API
mediante páginas que se cargan desde el mismo origen, que se define como
el esquema ( https:\\), host ( example.com), puerto ( 443) y dominio / reino
( example.com). Esto proporciona un acceso similar a estos datos como se
lograría al usar el secureindicador en una cookie, lo que significa que los datos
almacenados httpsno se pueden recuperar a través de http. Debido al posible
acceso simultáneo desde ventanas / subprocesos separados, los datos
almacenados utilizando localStoragepueden ser susceptibles a problemas de
acceso compartido (como condiciones de carrera) y deben considerarse sin
bloqueo ( especificación API de almacenamiento web ).

Duración
Los datos almacenados utilizando la localStorageAPI se conservan en las
sesiones de navegación, lo que extiende el período de tiempo en el que puede
ser accesible para otros usuarios del sistema.

Acceso sin conexión

Los estándares no requieren que los localStoragedatos se cifren en reposo, lo
que significa que es posible acceder directamente a estos datos desde el
disco.

Caso de uso
WHATWG sugiere el uso de localStoragedatos a los que se debe acceder a
través de ventanas o pestañas, a través de múltiples sesiones, y donde
grandes volúmenes de datos (de varios megabytes) pueden necesitar ser
almacenados por razones de rendimiento.

La API sessionStorage
Alcance
La sessionStorageAPI almacena datos dentro del contexto de la ventana desde
la que se llamó, lo que significa que la pestaña 1 no puede acceder a los datos
almacenados desde la pestaña 2. Además, al igual que la localStorageAPI,
las sessionStoragepáginas que se cargan desde el mismo origen pueden
acceder a los datos almacenados utilizando la API. , que se define como el
esquema ( https:\\), host ( example.com), puerto ( 443) y dominio / reino
( example.com). Esto proporciona un acceso similar a estos datos como se
lograría al usar el secureindicador en una cookie, lo que significa que los datos
almacenados httpsno se pueden recuperar a través de http.

Duración
La sessionStorageAPI solo almacena datos durante la sesión de navegación
actual. Una vez que se cierra la pestaña, esos datos ya no se pueden
recuperar. Esto no necesariamente impide el acceso, si una pestaña del
navegador se reutiliza o se deja abierta. Los datos también pueden persistir
en la memoria hasta un evento de recolección de basura.
Acceso sin conexión
Los estándares no requieren que los sessionStoragedatos se cifren en reposo,
lo que significa que es posible acceder directamente a estos datos desde el
disco.

Caso de uso
WHATWG sugiere el uso de sessionStoragedatos relevantes para una instancia
de un flujo de trabajo, como los detalles para la reserva de un ticket, pero
donde se podrían realizar múltiples flujos de trabajo en otras pestañas al
mismo tiempo. La naturaleza vinculada a la ventana / pestaña evitará que los
datos se filtren entre flujos de trabajo en pestañas separadas.

Riesgos de seguridad
En general, los datos seguros o confidenciales no deben almacenarse de
forma persistente en los almacenes de datos del navegador, ya que esto puede
permitir la filtración de información en sistemas compartidos. Debido a que los
mecanismos de almacenamiento web son API, esto también permite el acceso
desde los scripts inyectados, lo que lo hace menos seguro que las cookies con
el httponlyindicador aplicado. Si bien se podría defender el almacenamiento
de datos específicos del flujo de trabajo sessionStoragepara su uso en esa
pestaña / ventana específica en las recargas, las API de almacenamiento web
deben tratarse como un almacenamiento inseguro. Debido a esto, si una
solución de negocio requiere el uso de la localStorageosessionStoragePara
almacenar datos confidenciales, dicha solución debería cifrar los datos y
aplicar protecciones de reproducción. Debido a la posibilidad de acceder a las
API de almacenamiento web a través de un ataque XSS, los identificadores de
sesión deben almacenarse utilizando cookies no persistentes, con los
indicadores apropiados para proteger contra el acceso
inseguro ( Secure), XSS ( HttpOnly) y problemas CSRF ( SameSite).

Referencias
 API de almacenamiento web
 API LocalStorage
 API de SessionStorage
 WHATWG Especificaciones de almacenamiento web

ID de sesión Ciclo de vida

Generación y verificación de ID de sesión:
gestión de sesión permisiva y estricta
Existen dos tipos de mecanismos de administración de sesión para
aplicaciones web, permisivos y estrictos, relacionados con vulnerabilidades de
fijación de sesión. El mecanismo permisivo permite que la aplicación web
acepte inicialmente cualquier valor de ID de sesión establecido por el usuario
como válido, creando una nueva sesión para él, mientras que el mecanismo
estricto exige que la aplicación web solo acepte valores de ID de sesión que
hayan sido generados previamente por el usuario. Aplicación web.

Los tokens de sesión deben ser manejados por el servidor web si es posible o
generarse a través de un generador de números aleatorios criptográficamente
seguro.

Aunque el mecanismo más común en uso hoy en día es el estricto (más

seguro, PHP por defecto es permisivo ). Los desarrolladores deben
asegurarse de que la aplicación web no utilice un mecanismo permisivo bajo
ciertas circunstancias. Las aplicaciones web nunca deben aceptar una ID de
sesión que nunca hayan generado, y en caso de recibir una, deben generar y
ofrecer al usuario una nueva ID de sesión válida. Además, este escenario se
debe detectar como una actividad sospechosa y se debe generar una alerta.

Gestionar ID de sesión como cualquier

otra entrada de usuario
Las ID de sesión deben considerarse no confiables, como cualquier otra
entrada de usuario procesada por la aplicación web, y deben validarse y
verificarse exhaustivamente. Dependiendo del mecanismo de gestión de
sesión utilizado, la ID de sesión se recibirá en un parámetro GET o POST, en
la URL o en un encabezado HTTP (por ejemplo, cookies). Si las aplicaciones
web no validan y filtran los valores de ID de sesión no válidos antes de
procesarlos, pueden utilizarse para explotar otras vulnerabilidades de la web,
como la inyección de SQL si las ID de sesión se almacenan en una base de
datos relacional, o XSS persistente si las ID de sesión son almacenados y
reflejados posteriormente por la aplicación web.

Renueve la ID de sesión después de

cualquier cambio de nivel de privilegio
La aplicación web debe renovar o regenerar el ID de sesión después de
cualquier cambio de nivel de privilegio dentro de la sesión de usuario
asociada. El escenario más común donde la regeneración de ID de sesión es
obligatoria es durante el proceso de autenticación, ya que el nivel de privilegio
del usuario cambia del estado no autenticado (o anónimo) al estado
autenticado. También se deben considerar otros escenarios comunes, como
cambios de contraseña, cambios de permisos o cambio de un rol de usuario
normal a un rol de administrador dentro de la aplicación web. Para todas estas
páginas críticas de aplicaciones web, se deben ignorar las ID de sesión
anteriores, se debe asignar una nueva ID de sesión a cada nueva solicitud
recibida para el recurso crítico, y se debe destruir la ID de sesión anterior o
anterior.

Los marcos de desarrollo web más comunes proporcionan funciones y

métodos de sesión para renovar el ID de sesión,
como request.getSession(true)& HttpSession.invalidate()(J2EE), Session.Aba
ndon()& Response.Cookies.Add(new...) (ASP .NET)
o session_start()& session_regenerate_id(true) (PHP).
La regeneración de ID de sesión es obligatoria para evitar ataques de fijación
de sesión , donde un atacante establece la ID de sesión en el navegador web
del usuario de las víctimas en lugar de recopilar la ID de sesión de las víctimas,
como en la mayoría de los otros ataques basados en sesión, e
independientemente de usar HTTP o HTTPS Esta protección mitiga el impacto
de otras vulnerabilidades basadas en la web que también se pueden usar para
lanzar ataques de fijación de sesión, como la división de respuesta HTTP o
XSS (ver aquí y aquí ).

Una recomendación complementaria es utilizar una ID de sesión diferente o

un nombre de token (o un conjunto de ID de sesión) antes y después de la
autenticación, para que la aplicación web pueda realizar un seguimiento de
usuarios anónimos y usuarios autenticados sin el riesgo de exponer o vincular
la sesión de usuario entre ambos estados

Consideraciones al usar múltiples cookies

Si la aplicación web utiliza cookies como mecanismo de intercambio de ID de
sesión, y se configuran varias cookies para una sesión determinada, la
aplicación web debe verificar todas las cookies (y hacer cumplir las relaciones
entre ellas) antes de permitir el acceso a la sesión del usuario.

Es muy común que las aplicaciones web establezcan una autenticación previa
de cookies de usuario a través de HTTP para realizar un seguimiento de
usuarios no autenticados (o anónimos). Una vez que el usuario se autentica
en la aplicación web, se establece una nueva cookie segura posterior a la
autenticación a través de HTTPS, y se establece un enlace entre ambas
cookies y la sesión del usuario. Si la aplicación web no verifica ambas cookies
para las sesiones autenticadas, un atacante puede hacer uso de la cookie no
protegida previa a la autenticación para obtener acceso a la sesión del usuario
autenticado (ver aquí y aquí ).

Las aplicaciones web deben tratar de evitar el mismo nombre de cookie para
diferentes rutas o ámbitos de dominio dentro de la misma aplicación web, ya
que esto aumenta la complejidad de la solución y potencialmente introduce
problemas de alcance.

Caducidad de la sesión
Para minimizar el período de tiempo que un atacante puede lanzar ataques
sobre sesiones activas y secuestrarlos, es obligatorio establecer tiempos de
espera de vencimiento para cada sesión, estableciendo la cantidad de tiempo
que una sesión permanecerá activa. El vencimiento de sesión insuficiente por
parte de la aplicación web aumenta la exposición de otros ataques basados
en sesión, ya que para que el atacante pueda reutilizar una ID de sesión válida
y secuestrar la sesión asociada, aún debe estar activa.

Cuanto más corto es el intervalo de sesión, menor es el tiempo que un atacante

tiene que usar la ID de sesión válida. Los valores de tiempo de espera de
caducidad de la sesión deben establecerse de acuerdo con el propósito y la
naturaleza de la aplicación web, y equilibrar la seguridad y la usabilidad, para
que el usuario pueda completar cómodamente las operaciones dentro de la
aplicación web sin que su sesión caduque con frecuencia.

Los valores de tiempo de espera inactivo y absoluto dependen en gran medida

de la importancia de la aplicación web y sus datos. Los intervalos de tiempo
de inactividad comunes son de 2 a 5 minutos para aplicaciones de alto valor y
de 15 a 30 minutos para aplicaciones de bajo riesgo.

Cuando una sesión caduca, la aplicación web debe tomar acciones activas
para invalidar la sesión en ambos lados, cliente y servidor. Este último es el
más relevante y obligatorio desde una perspectiva de seguridad.

Para la mayoría de los mecanismos de intercambio de sesiones, las acciones

del lado del cliente para invalidar la ID de sesión se basan en borrar el valor
del token. Por ejemplo, para invalidar una cookie, se recomienda proporcionar
un valor vacío (o no válido) para la ID de sesión y establecer
el atributo Expires(o Max-Age) en una fecha del pasado (en caso de que se use
una cookie persistente): Set-Cookie: id=; Expires=Friday, 17-May-03 18:45:00
GMT
Para cerrar e invalidar la sesión en el lado del servidor, es obligatorio que la
aplicación web tome acciones activas cuando la sesión caduque, o el usuario
cierre sesión activamente, utilizando las funciones y métodos ofrecidos por los
mecanismos de administración de la sesión, como
como HttpSession.invalidate()(J2EE), Session.Abandon() (ASP .NET)
o session_destroy()/unset()(PHP).

Caducidad de sesión automática

Tiempo de inactividad
Todas las sesiones deben implementar un tiempo de inactividad o
inactividad. Este tiempo de espera define la cantidad de tiempo que una sesión
permanecerá activa en caso de que no haya actividad en la sesión, cerrando
e invalidando la sesión en el período inactivo definido desde la última solicitud
HTTP recibida por la aplicación web para una ID de sesión dada.

El tiempo de espera inactivo limita las posibilidades de que un atacante tenga

que adivinar y usar una ID de sesión válida de otro usuario. Sin embargo, si el
atacante puede secuestrar una sesión determinada, el tiempo de inactividad
no limita las acciones del atacante, ya que puede generar actividad en la
sesión periódicamente para mantenerla activa durante períodos más largos.
La gestión del tiempo de espera de la sesión y la caducidad deben aplicarse
en el lado del servidor. Si el cliente se usa para imponer el tiempo de espera
de la sesión, por ejemplo, utilizando el token de sesión u otros parámetros del
cliente para rastrear las referencias de tiempo (por ejemplo, el número de
minutos desde el tiempo de inicio de sesión), un atacante podría manipularlas
para extender la duración de la sesión.

Tiempo de espera absoluto

Todas las sesiones deben implementar un tiempo de espera absoluto,
independientemente de la actividad de la sesión. Este tiempo de espera define
la cantidad máxima de tiempo que una sesión puede estar activa, cerrando e
invalidando la sesión en el período absoluto definido desde que la aplicación
web creó inicialmente la sesión dada. Después de invalidar la sesión, el
usuario se ve obligado a (re) autenticarse nuevamente en la aplicación web y
establecer una nueva sesión.

La sesión absoluta limita la cantidad de tiempo que un atacante puede usar

una sesión secuestrada y hacerse pasar por el usuario víctima.

Tiempo de espera de renovación

Alternativamente, la aplicación web puede implementar un tiempo de espera
de renovación adicional después del cual el ID de la sesión se renueva
automáticamente, en medio de la sesión del usuario, e independientemente de
la actividad de la sesión y, por lo tanto, del tiempo de espera inactivo.

Después de un período de tiempo específico desde que se creó inicialmente

la sesión, la aplicación web puede regenerar una nueva ID para la sesión del
usuario e intentar configurarla o renovarla en el cliente. El valor de ID de sesión
anterior seguiría siendo válido durante algún tiempo, acomodando un intervalo
de seguridad, antes de que el cliente conozca la nueva ID y comience a
usarla. En ese momento, cuando el cliente cambia a la nueva ID dentro de la
sesión actual, la aplicación invalida la ID anterior.

Este escenario minimiza la cantidad de tiempo que un valor de ID de sesión

dado, potencialmente obtenido por un atacante, puede reutilizarse para
secuestrar la sesión del usuario, incluso cuando la sesión del usuario víctima
todavía está activa. La sesión de usuario permanece viva y abierta en el cliente
legítimo, aunque su valor de ID de sesión asociado se renueva de forma
transparente periódicamente durante la duración de la sesión, cada vez que
expira el tiempo de espera de renovación. Por lo tanto, el tiempo de espera de
renovación complementa los tiempos de espera inactivos y absolutos,
especialmente cuando el valor de tiempo de espera absoluto se extiende
significativamente a lo largo del tiempo (por ejemplo, es un requisito de la
aplicación mantener abiertas las sesiones de usuario durante largos períodos
de tiempo).
Dependiendo de la implementación, potencialmente podría haber una
condición de carrera en la que el atacante con una ID de sesión anterior aún
válida envía una solicitud antes del usuario víctima, justo después de que el
tiempo de espera de renovación acaba de expirar, y obtiene primero el valor
de la ID de sesión renovada. Al menos en este escenario, el usuario víctima
podría estar al tanto del ataque, ya que su sesión finalizará repentinamente
porque su ID de sesión asociada ya no es válida.

Caducidad manual de la sesión

Las aplicaciones web deben proporcionar mecanismos que permitan a los
usuarios conscientes de la seguridad cerrar activamente su sesión una vez
que hayan terminado de usar la aplicación web.

Botón de cerrar sesión

Las aplicaciones web deben proporcionar un botón de cierre de sesión visible
y de fácil acceso (cerrar sesión, salir o cerrar sesión) que esté disponible en el
encabezado o menú de la aplicación web y al que se pueda acceder desde
cada recurso y página de la aplicación web, de modo que el usuario pueda
cerrar manualmente la sesión en en cualquier momento. Como se describe en
la sección Sesión_Expiración , la aplicación web debe invalidar la sesión al
menos en el lado del servidor.

NOTA : Desafortunadamente, no todas las aplicaciones web facilitan a los

usuarios cerrar su sesión actual. Por lo tanto, las mejoras del lado del cliente
permiten a los usuarios conscientes proteger sus sesiones al ayudar a
cerrarlas diligentemente.

Almacenamiento en caché de contenido

web
Incluso después de que se haya cerrado la sesión, es posible acceder a los
datos privados o confidenciales intercambiados dentro de la sesión a través de
la memoria caché del navegador web. Por lo tanto, las aplicaciones web deben
utilizar directivas de caché restrictivas para todo el tráfico de Internet
intercambian a través de HTTP y HTTPS, tales como los Cache-
Controly Pragmalas páginas web sensibles cabeceras HTTP, y / o etiquetas
META equivalentes en todo o (al menos).
Independientemente de la política de caché definida por la aplicación web, si
se permite el almacenamiento en caché del contenido de la aplicación web, los
ID de sesión nunca deben almacenarse en caché, por lo que es muy
recomendable utilizar la Cache-Control: no-cache="Set-Cookie, Set-
Cookie2"directiva, para permitir que los clientes web almacenen en caché todo
excepto el ID de sesión (ver aquí )

Defensas adicionales del lado del

cliente para la gestión de sesiones
Las aplicaciones web pueden complementar las defensas de administración
de sesión descritas anteriormente con contramedidas adicionales en el lado
del cliente. Las protecciones del lado del cliente, generalmente en forma de
comprobaciones y verificaciones de JavaScript, no son a prueba de balas y
pueden ser fácilmente derrotadas por un atacante experto, pero pueden
introducir otra capa de defensa que los intrusos deben evitar.

Tiempo de espera de inicio de sesión

inicial
Las aplicaciones web pueden usar el código JavaScript en la página de inicio
de sesión para evaluar y medir la cantidad de tiempo desde que se cargó la
página y se otorgó una ID de sesión. Si se intenta un intento de inicio de sesión
después de un período de tiempo específico, el código del cliente puede
notificar al usuario que ha pasado el tiempo máximo para iniciar sesión y volver
a cargar la página de inicio de sesión, recuperando así una nueva ID de sesión.
Este mecanismo de protección adicional intenta forzar la renovación de la
autenticación previa de la ID de sesión, evitando escenarios en los que la
próxima víctima reutiliza una ID de sesión utilizada previamente (o configurada
manualmente) utilizando la misma computadora, por ejemplo, en ataques de
fijación de sesión.

Forzar cierre de sesión en la ventana del

navegador web Cerrar eventos
Las aplicaciones web pueden usar el código JavaScript para capturar todos
los eventos de cierre de ventana o pestaña (o incluso hacia atrás) del
navegador web y tomar las medidas apropiadas para cerrar la sesión actual
antes de cerrar el navegador web, emulando que el usuario ha cerrado
manualmente la sesión a través del cierre de sesión botón.

Deshabilitar sesiones de tabla cruzada del

navegador web
Las aplicaciones web pueden usar el código JavaScript una vez que el usuario
ha iniciado sesión y se ha establecido una sesión para obligarlo a volver a
autenticarse si se abre una nueva pestaña o ventana del navegador web en la
misma aplicación web. La aplicación web no quiere permitir que múltiples
pestañas o ventanas del navegador compartan la misma sesión. Por lo tanto,
la aplicación intenta forzar al navegador web a que no comparta la misma ID
de sesión simultáneamente entre ellos.

NOTA : Este mecanismo no se puede implementar si la ID de sesión se

intercambia a través de cookies, ya que las cookies son compartidas por todas
las pestañas / ventanas del navegador web.
Cierre de sesión automático del cliente
La aplicación web puede usar el código JavaScript en todas las páginas (o
críticas) para cerrar sesión automáticamente en las sesiones del cliente
después de que caduque el tiempo de inactividad, por ejemplo, redirigiendo al
usuario a la página de cierre de sesión (el mismo recurso utilizado por el botón
de cierre de sesión mencionado anteriormente) .

El beneficio de mejorar la funcionalidad de tiempo de espera inactivo del lado

del servidor con el código del lado del cliente es que el usuario puede ver que
la sesión ha finalizado debido a la inactividad, o incluso puede recibir una
notificación por adelantado de que la sesión está a punto de expirar a través
de un temporizador de cuenta regresiva y mensajes de advertencia. Este
enfoque fácil de usar ayuda a evitar la pérdida de trabajo en páginas web que
requieren datos de entrada extensos debido a sesiones caducadas
silenciosamente en el lado del servidor.

Detección de ataques de sesión

ID de sesión Adivinación y detección de
fuerza bruta
Si un atacante intenta adivinar o forzar por fuerza bruta una ID de sesión válida,
debe lanzar múltiples solicitudes secuenciales contra la aplicación web de
destino utilizando diferentes ID de sesión desde una sola (o conjunto de)
direcciones IP. Además, si un atacante intenta analizar la previsibilidad de la
ID de la sesión (p. Ej., Mediante análisis estadístico), debe lanzar múltiples
solicitudes secuenciales desde una sola (o conjunto de) direcciones IP contra
la aplicación web de destino para reunir nuevas aplicaciones válidas ID de
sesión.

Las aplicaciones web deben poder detectar ambos escenarios en función de

la cantidad de intentos de recopilar (o usar) diferentes ID de sesión y alertar y
/ o bloquear las direcciones IP infractoras.

Detección de anomalías de ID de sesión

Las aplicaciones web deberían centrarse en detectar anomalías asociadas a
la ID de sesión, como su
manipulación. El Proyecto OWASP AppSensor proporciona un marco y una
metodología para implementar capacidades integradas de detección de
intrusos dentro de las aplicaciones web enfocadas en la detección de
anomalías y comportamientos inesperados, en forma de puntos de detección
y acciones de respuesta. En lugar de usar capas de protección externas, a
veces los detalles de la lógica empresarial y la inteligencia avanzada solo
están disponibles desde el interior de la aplicación web, donde es posible
establecer múltiples puntos de detección relacionados con la sesión, como
cuando se modifica o elimina una cookie existente, una nueva cookie se
agrega, la ID de sesión de otro usuario se reutiliza, o cuando la ubicación del
usuario o el User-Agent cambian en medio de una sesión.

Enlace de la ID de sesión a otras

propiedades de usuario
Con el objetivo de detectar (y, en algunos escenarios, proteger contra) los
comportamientos incorrectos de los usuarios y el secuestro de sesiones, se
recomienda encarecidamente vincular la ID de la sesión a otras propiedades
del usuario o del cliente, como la dirección IP del cliente, el Agente de usuario
o el cliente certificado digital basado en Si la aplicación web detecta algún
cambio o anomalía entre estas diferentes propiedades en medio de una sesión
establecida, este es un muy buen indicador de la manipulación de la sesión y
los intentos de secuestro, y este simple hecho puede usarse para alertar y / o
terminar la sesión sospechosa. .
Aunque estas aplicaciones web no pueden usar estas propiedades para
defenderse con confianza de los ataques de sesión, aumentan
significativamente las capacidades de detección (y protección) de aplicaciones
web. Sin embargo, un atacante experto puede omitir estos controles
reutilizando la misma dirección IP asignada al usuario víctima compartiendo la
misma red (muy común en entornos NAT, como puntos de acceso Wi-Fi) o
utilizando el mismo proxy web saliente (muy común en entornos corporativos),
o modificando manualmente su User-Agent para que se vea exactamente
como lo hacen los usuarios víctimas.

Ciclo de vida de las sesiones de registro:

Monitoreo de la creación, uso y
destrucción de ID de sesión
Las aplicaciones web deberían aumentar sus capacidades de registro al incluir
información sobre el ciclo de vida completo de las sesiones. En particular, se
recomienda registrar eventos relacionados con la sesión, como la creación,
renovación y destrucción de ID de sesión, así como detalles sobre su uso
dentro de las operaciones de inicio y cierre de sesión, cambios de nivel de
privilegio dentro de la sesión, vencimiento del tiempo de espera, sesión no
válida actividades (cuando se detectan) y operaciones comerciales críticas
durante la sesión.

Los detalles del registro pueden incluir una marca de tiempo, una dirección IP
de origen, un recurso de destino web solicitado (e involucrado en una
operación de sesión), encabezados HTTP (incluido el Agente de usuario y
Referer), parámetros GET y POST, códigos y mensajes de error, nombre de
usuario (o ID de usuario), más la ID de sesión (cookies, URL, GET, POST ...).
Los datos confidenciales como la ID de sesión no deben incluirse en los
registros para proteger los registros de sesión contra la divulgación local o
remota de ID de sesión o el acceso no autorizado. Sin embargo, se debe iniciar
sesión en algún tipo de información específica de la sesión para correlacionar
las entradas de registro con sesiones específicas. Se recomienda registrar un
hash salado de la ID de sesión en lugar de la ID de sesión en sí para permitir
la correlación de registro específica de sesión sin exponer la ID de sesión.

En particular, las aplicaciones web deben proteger a fondo las interfaces

administrativas que permiten administrar todas las sesiones activas
actuales. Con frecuencia, estos son utilizados por el personal de soporte para
resolver problemas relacionados con la sesión, o incluso problemas generales,
personificando al usuario y mirando la aplicación web como lo hace el usuario.

Los registros de sesión se convierten en una de las principales fuentes de

datos de detección de intrusos de aplicaciones web, y también pueden ser
utilizados por los sistemas de protección contra intrusos para finalizar
automáticamente las sesiones y / o deshabilitar las cuentas de usuario cuando
se detectan (uno o muchos) ataques. Si se implementan protecciones activas,
estas acciones defensivas también deben registrarse.

Inicios de sesión simultáneos

Es la decisión del diseño de la aplicación web determinar si se permiten
múltiples inicios de sesión simultáneos del mismo usuario desde la misma o
desde diferentes direcciones IP del cliente. Si la aplicación web no desea
permitir inicios de sesión simultáneos, debe realizar acciones efectivas
después de cada nuevo evento de autenticación, finalizar implícitamente la
sesión disponible anteriormente o preguntar al usuario (a través de las
sesiones antiguas, nuevas o ambas) sobre la sesión que debe permanecer
activo

Se recomienda que las aplicaciones web agreguen capacidades de usuario

que permitan verificar los detalles de las sesiones activas en cualquier
momento, monitorear y alertar al usuario sobre inicios de sesión concurrentes,
proporcionar funciones de usuario para finalizar sesiones de forma remota
manualmente y rastrear el historial de actividad de la cuenta (libro de registro)
mediante grabación múltiples detalles del cliente, como la dirección IP, User-
Agent, fecha y hora de inicio de sesión, tiempo de inactividad, etc.

Gestión de sesiones Protecciones

WAF
Hay situaciones en las que el código fuente de la aplicación web no está
disponible o no se puede modificar, o cuando los cambios necesarios para
implementar las múltiples recomendaciones de seguridad y las mejores
prácticas detalladas anteriormente implican un rediseño completo de la
arquitectura de la aplicación web y, por lo tanto, no se pueden implementar
fácilmente A corto plazo.
En estos escenarios, o para complementar las defensas de la aplicación web,
y con el objetivo de mantener la aplicación web lo más segura posible, se
recomienda utilizar protecciones externas como los firewalls de aplicaciones
web (WAF) que pueden mitigar las amenazas de administración de sesión ya
descritas .

Los firewalls de aplicaciones web ofrecen capacidades de detección y

protección contra ataques basados en sesiones. Por un lado, es trivial que los
WAF impongan el uso de atributos de seguridad en las cookies, como
las banderas Securey HttpOnly, aplicando reglas básicas de reescritura en
el Set-Cookieencabezado para todas las respuestas de la aplicación web que
establecen una nueva cookie.
Por otro lado, se pueden implementar capacidades más avanzadas para
permitir que el WAF haga un seguimiento de las sesiones y las ID de sesión
correspondientes, y aplique todo tipo de protecciones contra la fijación de la
sesión (renovando la ID de la sesión en el lado del cliente cuando cambia el
privilegio) se detectan), imponiendo sesiones fijas (verificando la relación entre
el ID de la sesión y otras propiedades del cliente, como la dirección IP o el
Agente de usuario) o administrando la caducidad de la sesión (obligando tanto
al cliente como a la aplicación web a finalizar la sesión) .

El ModSecurity WAF de código abierto, más el conjunto de reglas

principales OWASP , proporciona capacidades para detectar y aplicar
atributos de cookies de seguridad, contramedidas contra ataques de fijación
de sesión y características de seguimiento de sesión para imponer sesiones
fijas.