En sécurisant les configurations INI de sessions, les développeurs
peuvent éprouver la sécurité des sessions. Beaucoup de configurations
INI n'ont pas de configuration recommandée. Les développeurs sont
responsables de la bonne configuration des sessions.
-
session.cookie_lifetime=0
La valeur 0
a une signification importante.
Elle informe les navigateurs de ne pas stocker le cookie dans un
espace de stockage permanent. Aussi, lorsque le navigateur se ferme,
le cookie d'identification de session est supprimé immédiatement.
Si les développeurs définissent une valeur différente de 0, cela permet
aux autres utilisateurs d'utiliser l'identifiant de session. La
plupart des application devrait utiliser "0
" comme
valeur.
Si une fonctionnalité d'auto-identification est désirée, les développeurs
doivent implémenter leur propre système d'auto-identification sécurité.
N'utilisez pas des idenfiants de session à longue durée pour celà.
Pour plus d'informations, veuillez vous rapporter à la bonne section
de cette documentation.
-
session.use_cookies=On
session.use_only_cookies=On
Bien que les cookies HTTP souffrent de soucis techniques, ils
restent la façon préférée de gérer les identifiants de sessions.
N'utilisez que les cookies pour la gestion des identifiants de sessions
lorsque cela est possible. La plupart des applications doivent utiliser
un cookie pour l'identifiant de session.
Si session.use_only_cookies=Off,
le module de session utilisera les valeurs de l'identifiant
de sessions définies par les variables GET ou POST fournies,
et le cookie de l'identifiant de session ne sera pas initialisé.
-
session.use_strict_mode=On
Bien que l'activation de session.use_strict_mode
soit obligatoire pour la sécurité des sessions, cette directive est
désactivée par défaut.
Ce mode évite que le module de session utilise un identifiant de session
non initialisé. Dit différemment, le module de session ne va accepter
que les identifiants de sessions valides générés par le module de session.
Il va rejeter tous les identifiants de session fournis par les utilisateurs.
En raison de la spécification des cookies, les attaquants sont capable
de placer des cookies contenant les identifiants de sessions en configurant
localement une base de données de cookie ou par injections Javascript.
session.use_strict_mode peut éviter qu'un attaquant
n'initialise un identifiant de session.
Note:
Les attaquants peuvent initialiser un identifiant de session avec leur
propre périphérique, et peuvent définir l'identifiant de session
de leur victime. Ils doivent alors conserver l'identifiant de session
actif pour pouvoir en abuser.
Les attaquants doivent passer par bien d'autres étapes pour réussir leur attaque
dans ce scénario. Aussi, l'utilisation de la directive
session.use_strict_mode permet de limiter les risques.
-
session.cookie_httponly=On
Permet de refuser l'accès à un cookie de session depuis javascript.
Cette configuration évite qu'un cookie ne soit corrompu par une
injection Javascript.
Il est possible d'utiliser un identifiant de session comme jeton CSRF, mais
ce n'est pas recommandé. Par exemple, des sources HTML peuvent être
sauvegardées et envoyées à d'autres utilisateurs.
Les développeurs ne doivent pas écrire les identifiants de session dans les
pages web pour des raisons de sécurité. Toutes les applications web doivent
utiliser l'attribut httponly pour le cookie contenant l'identifiant de session.
Note:
Le jeton CSRF doit être renouvellé périodiquement, tout comme l'identifiant
de session.
-
session.cookie_secure=On
Permet d'accéder au cookie d'identifiant de session uniquement lorsque
le protocole est HTTPS. Si un site web n'est accessible que par HTTPS,
cette directive doit être activée.
HSTS doit être utilisé pour les sites web accessibles que par HTTPS.
-
session.cookie_samesite="Lax" ou
session.cookie_samesite="Strict"
Depuis PHP 7.3, l'attribut "SameSite"
peut être défini
pour le cookie d'identifiant de session. Cet attribut est une façon de
mitiger les attaques CSRF (Cross Site Request Forgery).
La différence entre Lax et Strict est l'accessibilité du cookie dans les requêtes
originaires d'autres domaines employant la méthode HTTP GET.
Les cookies utilisant Lax seront accessible via une requête GET originaire
d'un autre domaine, alors que les cookies utilisant Strict ne le seront pas..
-
session.gc_maxlifetime=[choisissez le plus petit possible]
session.gc_maxlifetime est une configuration pour supprimer
l'identifiant de session obsolète. Le fait de se reposer
entièrement sur cette configuration n'est pas recommandé.
Les développeurs doivent gérer la durée de vie des session avec un timestamp
par eux même.
Le GC des sessions (garbage collection) est mieux réalisé en utilisant
la fonction session_gc().
La fonction session_gc() doit être exécutée par un gestionnaire
de tâches ; i.e. un cron sur les systèmes Unix.
GC est exécuté par probabilité, par défaut. Cette configuration
ne garantie pas que les anciennes sessions soient
supprimées. Bien que les développeurs ne doivent pas s'appuyer sur ce paramètre,
il est recommandé tout de même de le définir à une valeur la plus petite possible.
Il convient d'ajuster les directives session.gc_probability
et session.gc_divisor de sorte à ce que
les sessions obsolètes soient supprimées à fréquence appropriée.
Si la fonctionnalité d'auto-identification est nécessaire, les développeurs
doivent implémenter leur propre fonctionnalité d'auto-identification sécurisée ;
voir ci-dessous pour plus d'informations. N'utilisez jamais l'identifiant
de session de longue durée pour réaliser ce genre de fonctionnalité.
Note:
Quelques modules de gestion de sauvegarde des sessions n'utilisent pas cette
fonctionnalité basé sur l'expiration et sur la probabilité ; i.e.
memcached, memcache. Référez vous à la documentation de ces gestionnaires
de sauvegarde des sessions pour plus de détails.
-
session.use_trans_sid=Off
L'utilisation d'un gestionnaire d'identifiants de sessions transparent
n'est pas interdit. Les développeurs doivent l'employer lorsque nécessaire.
Pourtant, la désactivation de la gestion des identifiants de session de
façon transparente permet de sécuriser un peu plus les identifiants de session
en éliminant la possibilité d'une injection d'identifiant de sessions ou
de fuite de cet identifiant.
Note:
L'identifiant de session peut fuiter depuis des URLs sauvegardées,
des URLs dans des emails, d'une source HTML sauvegardée, etc...
-
session.trans_sid_tags=[drapeaux limités]
(PHP 7.1.0 >=) Les développers ne doivent pas réécrire de drapeaux HTML
non nécessaires. La valeur par défaut doit être suffisante pour la
plupart des utilisations. Pour les versions de PHP plus anciennes,
utilisez plutôt
url_rewriter.tags.
-
session.trans_sid_hosts=[hôtes limités]
(PHP 7.1.0 >=) Ce paramètre définit une liste blanche des hôtes qui sont
autorisés à réécrire les identifiants de session transparents. Ne jamais
ajouter d'hôte qui ne sont pas de confiance !
Le module de session autorise uniquement $_SERVER['HTTP_HOST']
lorsque ce paramètre est vide.
-
session.referer_check=[URL d'origine]
Lorsque le paramètre session.use_trans_sid
est actif.
Ce paramètre réduit les risques d'injection d'identifiant de session.
Si un site web est http://example.com/
,
définissez comme valeur à ce paramètre http://example.com/
.
Notez que les navigateurs HTTPS n'envoient pas l'en-tête referrer.
Les navigateurs peuvent ne pas envoyer l'en-tête referrer de part
leur propre configuration. Aussi, ce paramètre ne peut pas être
considéré comme une mesure fiable de sécurité.
Malgré tout, son utilisation est recommandée.
-
session.cache_limiter=nocache
S'assure que le contenu HTTP n'est pas mis en cache pour les sessions
authentifiées. Permet la mise en cache que pour les contenus
qui ne sont pas privés. Sinon, le contenu sera exposé.
La valeur "private"
doit être employé si le contenu HTTP n'inclut pas
des données sensibles d'un point de vue sécurité. Notez que "private"
peut transmettre des données privées mises en cache pour les clients
partagés. "public"
doit être uniquement utilisé lorsque le contenu HTML
ne contient aucune donnée privée.
-
session.sid_length="48"
(PHP 7.1.0 >=) La longueur des identifiants de session permet
d'avoir des identifiants de session plus fort.
Les développeurs doivent utiliser des identifiants de session
d'au moins 32 caractères. Au moins 26 caractères sont requis lorsque
session.sid_bits_per_character="5".
-
session.sid_bits_per_character="6"
(PHP 7.1.0 >=) Le nombre d'octets présents dans un caractère d'identifiant
de sessions.
-
session.hash_function="sha256"
(PHP 7.1.0 <) Une fonction de hachage forte va générer un identifiant
de session fort. Bien qu'une collision de hachage soit peu probable avec des
algorithme de hachage MD5, les développeurs doivent utiliser SHA-2 ou un
algorithme de hachage plus fort comme sha384 et sha512.
Les développeurs doivent s'assurer d'une longueur suffisante de
l'entropie pour la
fonction de hachage utilisée.
-
session.save_path=[dossier non lisible par tout le monde]
Si ce paramètre est définit à un dossier accessible en lecture par tout le monde,
comme /tmp (par défaut), les autres utilisateurs du serveur
seront capables de récupérer les sessions en listant les fichiers présents
dans ce répertoire.