Sécurisation des configurations INI de session

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 applications devraient 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écurisé. Ne pas utiliser d'identifiants de session à longue durée pour cela. Pour plus d'informations, se 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'utiliser 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 capables 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 renouvelé 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"

  À partir de 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 accessibles 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 sessions avec un timestamp par eux-mêmes.

  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 ; c.-à-d. un cron sur les systèmes Unix.

  GC est exécuté par probabilité, par défaut. Cette configuration ne garantit 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'utiliser 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ée sur l'expiration et sur la probabilité ; c.-à-d. memcached, memcache. Se référer à 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=[balises limitées]

  (PHP 7.1.0 >=) Les développeurs ne devraient pas réécrire de balises HTML non nécessaires. La valeur par défaut doit être suffisante pour la plupart des utilisations. Pour les versions de PHP plus anciennes, utiliser 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/. Il est à noter 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ée si le contenu HTTP n'inclut pas des données sensibles d'un point de vue sécurité. Il est à noter 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.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 algorithmes 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éfini à 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.