Les sessions PHP permettent à un site web de mémoriser les données des utilisateurs entre les requêtes de pages, comme un statut de connexion ou un panier d’achat. Les paramètres par défaut ne sont cependant pas toujours suffisamment sécurisés pour les environnements de production. Dans cet article, découvrez le fonctionnement des sessions, les paramètres php.ini importants, et les mesures concrètes pour protéger les sessions contre le hijacking et la fixation.
Comment fonctionnent les sessions PHP
Lorsqu’un visiteur accède à un site web utilisant des sessions, PHP crée un identifiant de session unique. Cet identifiant est généralement stocké dans un cookie (PHPSESSID) chez le visiteur et utilisé pour retrouver les données correspondantes sur le serveur, par exemple dans un fichier ou une base de données. À chaque requête suivante, le navigateur renvoie ce cookie, afin que le serveur sache quelles données de session correspondent à quel visiteur.
Le problème survient lorsque cet identifiant de session est intercepté ou deviné. Un attaquant qui l’obtient peut se faire passer pour l’utilisateur connecté sans avoir besoin de mot de passe. Une bonne configuration des sessions est donc tout aussi importante qu’une politique de mots de passe robuste.
Paramètres php.ini importants
Les paramètres suivants dans php.ini (ou dans un fichier .user.ini pour l’hébergement mutualisé) déterminent la sécurité des sessions :
session.cookie_httponly = 1– empêche JavaScript d’accéder au cookie de session, ce qui rend les attaques XSS moins dangereuses.session.cookie_secure = 1– garantit que le cookie n’est envoyé que via HTTPS, jamais en clair.session.cookie_samesite = StrictouLax– limite l’envoi du cookie lors de requêtes provenant d’autres sites et réduit les risques de CSRF.session.use_strict_mode = 1– empêche PHP d’accepter un identifiant de session inventé par un attaquant.session.gc_maxlifetime– détermine la durée pendant laquelle une session inactive reste valide avant d’être nettoyée.session.name– remplacez le nom par défaut PHPSESSID par quelque chose d’unique, afin que les outils de scan automatiques identifient moins facilement la technologie utilisée.
Sécuriser les sessions contre le hijacking et la fixation
Outre les paramètres php.ini, il existe des mesures à mettre en œuvre dans votre propre code d’application :
Régénérez l’identifiant de session après la connexion
Appelez session_regenerate_id(true) immédiatement après une connexion réussie. Cela empêche la fixation de session, où un attaquant fait utiliser à un visiteur un identifiant de session prédéfini.
Vérifiez l’adresse IP et le user-agent
Enregistrez l’adresse IP et le user-agent au démarrage d’une session, et comparez-les à chaque requête. En cas de changement inattendu, vous pouvez faire expirer la session.
Définissez un délai d’expiration raisonnable
Faites expirer automatiquement les sessions après une période d’inactivité, à la fois via session.gc_maxlifetime et un contrôle d’horodatage propre dans le code.
Détruisez correctement les sessions à la déconnexion
Utilisez session_unset(), session_destroy() et supprimez explicitement le cookie, afin qu’aucune donnée résiduelle ne subsiste.
Forcez toujours HTTPS
Sans certificat SSL valide, un cookie de session peut être intercepté sur des connexions non sécurisées. Assurez-vous que votre site n’est accessible que via HTTPS.
Configurer les sessions dans Plesk
Avec un hébergement sous Plesk, vous pouvez appliquer des paramètres PHP personnalisés par domaine via les paramètres PHP de l’abonnement, ou via un fichier php.ini propre dans les paramètres d’hébergement. Vous pouvez ainsi définir des valeurs différentes pour cookie_secure, cookie_samesite ou gc_maxlifetime par site web, sans modifier la configuration globale du serveur. Sur un stockage NVMe avec LiteSpeed, ces paramètres sont traités immédiatement, sans ralentissement notable pour les visiteurs.
Vous vous demandez si votre environnement d’hébergement actuel prend bien en charge la sécurité PHP ? Découvrez les possibilités d’hébergement web à prix fixes et avec SSL gratuit, ou lisez comment fonctionne le passage à Tandata si la sécurisation de vos sessions n’est actuellement pas bien assurée.
Questions fréquentes
Pourquoi mes sessions ne fonctionnent-elles plus après avoir activé cookie_secure ?
Si votre site fonctionne encore en HTTP au lieu de HTTPS, le cookie n’est pas envoyé dès que cookie_secure est activé. Vérifiez que votre certificat SSL est actif et valide.
L’utilisation de sessions est-elle plus sûre que les jetons JWT ?
Les deux ont des avantages et des inconvénients. Les sessions sont plus faciles à révoquer côté serveur, tandis que les jetons JWT sont sans état (stateless). Pour la plupart des sites web classiques, des sessions bien configurées sont suffisamment sécurisées.
Quelle valeur dois-je définir pour session.gc_maxlifetime ?
Cela dépend de votre application. Pour une boutique en ligne ou un site informatif, une durée de vie plus courte suffit souvent, tandis qu’un tableau de bord où les utilisateurs restent longtemps connectés peut nécessiter une valeur plus longue.
Puis-je également stocker les fichiers de session dans une base de données ?
Oui, avec un gestionnaire de session personnalisé, vous pouvez stocker les données de session dans MySQL par exemple, au lieu de fichiers. Ceci est utile en cas de répartition de charge (load balancing) sur plusieurs serveurs.
Où puis-je trouver plus d’informations sur les paramètres serveur ?
La base de connaissances contient davantage d’articles sur la configuration PHP, le SSL et la gestion de serveur.
Conclusion
Des sessions PHP bien configurées protègent les données des utilisateurs contre le hijacking et la fixation. Veillez à avoir les bons paramètres php.ini, régénérez les identifiants de session après la connexion, forcez HTTPS et détruisez correctement les sessions à la déconnexion. Avec le bon environnement d’hébergement, vous appliquez facilement ces paramètres sans compromis sur la rapidité.