Al asegurar las configuraciones INI de sesiones, los desarrolladores pueden experimentar la seguridad de las sesiones. Muchas configuraciones INI no tienen una configuración recomendada. Los desarrolladores son responsables de la correcta configuración de las sesiones.
El valor 0 tiene un significado importante.
Informa a los navegadores de no almacenar la cookie en un
espacio de almacenamiento permanente. También, cuando el navegador se cierra,
la cookie de identificación de sesión es eliminada inmediatamente.
Si los desarrolladores definen un valor diferente de 0, permite
a otros usuarios utilizar el identificador de sesión. La
mayoría de las aplicaciones deben utilizar "0" como
valor.
Si se desea una funcionalidad de auto-identificación, los desarrolladores deben implementar su propio sistema de auto-identificación seguro. No utilice identificadores de sesión de larga duración para esto. Para más información, consulte la sección adecuada de esta documentación.
Aunque las cookies HTTP sufren de problemas técnicos, siguen siendo la forma preferida de gestionar los identificadores de sesiones. Utilice solo cookies para la gestión de identificadores de sesiones cuando sea posible. La mayoría de las aplicaciones deben utilizar una cookie para el identificador de sesión.
Si session.use_only_cookies=Off, el módulo de sesión utilizará los valores del identificador de sesión definidos por las variables GET o POST proporcionadas, y la cookie del identificador de sesión no será inicializada.
Aunque la activación de session.use_strict_mode es obligatoria para la seguridad de las sesiones, esta directiva está desactivada por defecto.
Este modo evita que el módulo de sesión utilice un identificador de sesión no inicializado. Dicho de otra forma, el módulo de sesión solo va a aceptar identificadores de sesiones válidos generados por el módulo de sesión. Rechazará todos los identificadores de sesión proporcionados por los usuarios.
Debido a la especificación de cookies, los atacantes son capaces de colocar cookies que contienen identificadores de sesiones configurando localmente una base de datos de cookies o mediante inyecciones Javascript. session.use_strict_mode puede evitar que un atacante inicialice un identificador de sesión.
Nota:
Los atacantes pueden inicializar un identificador de sesión con su propio dispositivo, y pueden definir el identificador de sesión de su víctima. Deben entonces mantener el identificador de sesión activo para poder abusar de él. Los atacantes deben pasar por muchos otros pasos para tener éxito en su ataque en este escenario. También, el uso de la directiva session.use_strict_mode permite limitar los riesgos.
Permite rechazar el acceso a una cookie de sesión desde javascript. Esta configuración evita que una cookie sea corrompida por una inyección Javascript.
Es posible utilizar un identificador de sesión como token CSRF, pero no es recomendado. Por ejemplo, fuentes HTML pueden ser guardadas y enviadas a otros usuarios. Los desarrolladores no deben escribir los identificadores de sesión en las páginas web por razones de seguridad. Todas las aplicaciones web deben utilizar el atributo httponly para la cookie que contiene el identificador de sesión.
Nota:
El token CSRF debe ser renovado periódicamente, al igual que el identificador de sesión.
Permite acceder a la cookie de identificador de sesión únicamente cuando el protocolo es HTTPS. Si un sitio web solo es accesible por HTTPS, esta directiva debe ser activada.
HSTS debe ser utilizado para los sitios web accesibles solo por HTTPS.
session.cookie_samesite="Lax" o session.cookie_samesite="Strict"
Desde PHP 7.3, el atributo "SameSite" puede ser definido
para la cookie de identificador de sesión. Este atributo es una forma de
mitigar los ataques CSRF (Cross Site Request Forgery).
La diferencia entre Lax y Strict es la accesibilidad de la cookie en las peticiones originadas de otros dominios empleando el método HTTP GET. Las cookies utilizando Lax serán accesibles mediante una petición GET originada de otro dominio, mientras que las cookies utilizando Strict no lo serán.
session.gc_maxlifetime=[elija el más pequeño posible]
session.gc_maxlifetime es una configuración para eliminar el identificador de sesión obsoleto. Confiar completamente en esta configuración no es recomendado. Los desarrolladores deben gestionar la duración de las sesiones con un timestamp por ellos mismos.
La GC de sesiones (recolección de basura) es mejor realizada utilizando la función session_gc(). La función session_gc() debe ser ejecutada por un gestor de tareas; por ejemplo, un cron en los sistemas Unix.
GC es ejecutado por probabilidad, por defecto. Esta configuración no garantiza que las sesiones antiguas sean eliminadas. Aunque los desarrolladores no deben basarse en este parámetro, se recomienda definirlo con el valor más pequeño posible. Debe ajustarse las directivas session.gc_probability y session.gc_divisor de modo que las sesiones obsoletas sean eliminadas con la frecuencia apropiada. Si la funcionalidad de auto-identificación es necesaria, los desarrolladores deben implementar su propia funcionalidad de auto-identificación segura; consulte a continuación para más información. Nunca utilice el identificador de sesión de larga duración para realizar este tipo de funcionalidad.
Nota:
Algunos módulos de gestión de guardado de sesiones no utilizan esta funcionalidad basada en expiración y probabilidad; por ejemplo, memcached, memcache. Consulte la documentación de estos gestores de guardado de sesiones para más detalles.
La desactivación de la gestión transparente de identificadores de sesión permite asegurar un poco más los identificadores de sesión, eliminando la posibilidad de una inyección de identificador de sesión o la fuga de este identificador.
Habilitar session.use_trans_sid está obsoleto a partir
de PHP 8.4.0.
Nota:
El identificador de sesión puede filtrarse desde URLs guardadas, URLs en emails, una fuente HTML guardada, etc...
session.trans_sid_tags="a=href,area=href,frame=src,form="
No deben reescribirse etiquetas HTML innecesarias. El valor por defecto es suficiente para la mayoría de los usos. Para versiones de PHP más antiguas, utilice en su lugar url_rewriter.tags.
Modificar session.trans_sid_tags respecto a su valor
por defecto está obsoleto a partir de PHP 8.4.0.
Este parámetro enumera los hosts para los que el identificador de sesión
puede añadirse a las URL. Nunca deben añadirse hosts que no sean de
confianza. Cuando está vacío, el módulo de sesión solo autoriza
$_SERVER['HTTP_HOST'].
Establecer session.trans_sid_hosts a un valor no vacío
está obsoleto a partir de PHP 8.4.0.
Cuando el parámetro session.use_trans_sid
está activo, un valor no vacío reduce los riesgos de inyección de
identificador de sesión: el identificador de sesión enviado por el cliente
se descarta salvo que el encabezado Referer contenga ese
valor. Tenga en cuenta que con HTTPS los navegadores no envían el
encabezado Referer, y que los navegadores pueden
omitirlo debido a su propia configuración. Por lo tanto, este parámetro no
puede ser considerado como una medida fiable de seguridad.
Establecer session.referer_check a un valor no vacío
está obsoleto a partir de PHP 8.4.0.
session.cache_limiter=nocache
Asegura que el contenido HTTP no sea almacenado en caché para las sesiones
autenticadas. Permite el almacenamiento en caché solo para los contenidos
que no son privados. De lo contrario, el contenido será expuesto.
El valor "private" debe ser empleado si el contenido HTTP no incluye
datos sensibles desde un punto de vista de seguridad. Tenga en cuenta que "private"
puede transmitir datos privados almacenados en caché para los clientes
compartidos. "public" solo debe ser utilizado cuando el contenido HTML
no contiene ningún dato privado.
session.save_path=[directorio no legible por todos]
Si este parámetro está definido a un directorio accesible en lectura por todos, como /tmp (por defecto), otros usuarios del servidor serán capaces de recuperar las sesiones listando los archivos presentes en este directorio.
It is important to realize that session.cookie_lifetime=0 will delete the cookie when the browser closes but nowadays browers tend to never close even after the last windows or tab was closed.
For startup speed purposes and to retrieve push traffic browser drop to the background hence the cookie stays put.