A voir également:
- Detruire session php
- Alert php ✓ - Forum PHP
- Easy php - Télécharger - Divers Web & Internet
- Session expirée facebook piratage ✓ - Forum Facebook
- Session invalide ou obsolète - Forum Consommation & Internet
- Estelle vient de verrouiller sa session d'ordinateur. que peut-on dire ? - Forum Windows
16 réponses
Afin de mettre fin à des débats qui ne répondent pas à la question, voici quelques précisions:
un cookie est un fichier écrit côté client, sur l'ordinateur de l'internaute
une session est un fichier ayant caractère de cookie écrit côté serveur qui héberge le site.
Une session est identifiée par un cookie comportant l'id de la session, elle est donc propre à chaque internaute, mais dispose d'informations que seul le serveur peut lire.
Lorsque vous fermez votre navigateur, le serveur ne le sait pas, seul votre navigateur sait qu'il doit détruire les cookies à durée de vie non précisée, incluant la plupart du temps, le cookie comprenant l'id de session.
Par conséquent, la session n'est pas détruite mais il est très difficile de la retrouver. Néanmoins, même si la faille est petite, elle existe, et les considérations liées à la sécurité sont justifiées.
S'appuyer sur une fonction ajax lors d'un évènement onclose n'est pas une solution robuste, car cet évènement n'est pas reconnu par tous les navigateurs. De même, l'évènement unload se produit à chaque changement de page, il n'est probablement pas souhaitable de détruire une session (ce qui déconnecterait un utilisateur enregistré) lors du passage d'une page à l'autre du même site.
L'existence d'un moyen de déconnexion est une pratique de bon sens et d'ergonomie indispensable. Néanmoins, presque tous les internautes quittent les sites web où ils naviguent sans se déconnecter (à part leur banque peut être...).
Si une personne malveillante parvient à déterminer une id de session sur un fichier existant sur le serveur, cette personne pourra usurper l'identité de l'internaute à qui appartenait cette session (Bon ok, faut utiliser un programme qui teste des tonnes de clés, c'est donc peu probable, mais possible, les mesures de sécurités sont donc fonction de la sensibilité des données protégées).
Afin de prévenir ce risque, le seul moyen (que je connaisse) est de limiter la durée de vie du cookie identifiant la session, par la fonction PHP session_set_cookie_params(lifetime), lifetime étant la durée de vie en secondes.
Ainsi, en écrivant session_set_cookie_params(600), avant d'appeler session_start(), la session deviendra inactive au bout de 10 minutes, déconnectant par la même occasion l'internaute inactif sur le site.
Si vous désirez véritablement forcer l'effacement de ces fichiers session sur votre serveur, vous pouvez agir sur les directives session.gc_probability et session.gc_divisor de sorte à augmenter les probabilités d'action du garbage collector sur les sessions périmées, leur délai de péremption étant défini par la directive session.gc_maxlifetime (en seconde). Ces directives figurent dans le php.ini et nécessitent un redémarrage des services après modification.
Pour plus d'information, se référer à ces pages:
https://www.php.net/manual/fr/ref.session.php
https://www.php.net/manual/fr/session.configuration.php#ini.session.cookie-secure
un cookie est un fichier écrit côté client, sur l'ordinateur de l'internaute
une session est un fichier ayant caractère de cookie écrit côté serveur qui héberge le site.
Une session est identifiée par un cookie comportant l'id de la session, elle est donc propre à chaque internaute, mais dispose d'informations que seul le serveur peut lire.
Lorsque vous fermez votre navigateur, le serveur ne le sait pas, seul votre navigateur sait qu'il doit détruire les cookies à durée de vie non précisée, incluant la plupart du temps, le cookie comprenant l'id de session.
Par conséquent, la session n'est pas détruite mais il est très difficile de la retrouver. Néanmoins, même si la faille est petite, elle existe, et les considérations liées à la sécurité sont justifiées.
S'appuyer sur une fonction ajax lors d'un évènement onclose n'est pas une solution robuste, car cet évènement n'est pas reconnu par tous les navigateurs. De même, l'évènement unload se produit à chaque changement de page, il n'est probablement pas souhaitable de détruire une session (ce qui déconnecterait un utilisateur enregistré) lors du passage d'une page à l'autre du même site.
L'existence d'un moyen de déconnexion est une pratique de bon sens et d'ergonomie indispensable. Néanmoins, presque tous les internautes quittent les sites web où ils naviguent sans se déconnecter (à part leur banque peut être...).
Si une personne malveillante parvient à déterminer une id de session sur un fichier existant sur le serveur, cette personne pourra usurper l'identité de l'internaute à qui appartenait cette session (Bon ok, faut utiliser un programme qui teste des tonnes de clés, c'est donc peu probable, mais possible, les mesures de sécurités sont donc fonction de la sensibilité des données protégées).
Afin de prévenir ce risque, le seul moyen (que je connaisse) est de limiter la durée de vie du cookie identifiant la session, par la fonction PHP session_set_cookie_params(lifetime), lifetime étant la durée de vie en secondes.
Ainsi, en écrivant session_set_cookie_params(600), avant d'appeler session_start(), la session deviendra inactive au bout de 10 minutes, déconnectant par la même occasion l'internaute inactif sur le site.
Si vous désirez véritablement forcer l'effacement de ces fichiers session sur votre serveur, vous pouvez agir sur les directives session.gc_probability et session.gc_divisor de sorte à augmenter les probabilités d'action du garbage collector sur les sessions périmées, leur délai de péremption étant défini par la directive session.gc_maxlifetime (en seconde). Ces directives figurent dans le php.ini et nécessitent un redémarrage des services après modification.
Pour plus d'information, se référer à ces pages:
https://www.php.net/manual/fr/ref.session.php
https://www.php.net/manual/fr/session.configuration.php#ini.session.cookie-secure
