Quand et pourquoi devrais-je utiliser session_regenerate_id ()?


95

Pourquoi et quand utiliser la session_regenerate_id()fonction en php? Dois-je toujours l'utiliser après avoir utilisé le session_start()? J'ai lu que je devais l'utiliser pour éviter la fixation de session, est-ce la seule raison?


car après le début de la session, le est est créé et sur l'autre page lorsque vous démarrez la session, les variables sont présentes: -
HaRsH

@HaRsH Oo? Session_regenerate_id supprime l'ancien identifiant de session et en crée un nouveau pour éviter de détourner la session avec XSS par exemple. Cela n'a aucun effet sur la visibilité des variables SESSION dans d'autres documents.
Xatenev

oui je sais que je n'ai aucun effet sur une autre variable mais si vous ne démarrez pas la session sur cette page, la variable n'est pas présente sur cette page dans le noyau php
HaRsH

1
Mais il s'agit de session_regenerate_id, pas de session_start ...
Xatenev

1
Je suggère de lire la RFC où elle a été proposée: wiki.php.net/rfc/precise_session_management
jankal

Réponses:


96

Qu'est-ce que c'est session_regenerate_id()?

Comme le nom de la fonction l'indique, il s'agit d'une fonction qui remplacera l'ID de session actuel par un nouveau et conservera les informations de session en cours.

Qu'est ce que ça fait?

Il aide principalement à prévenir les attaques de fixation de session. Les attaques de fixation de session sont lorsqu'un utilisateur malveillant tente d'exploiter la vulnérabilité d'un système pour fixer (définir) l'ID de session (SID) d'un autre utilisateur. Ce faisant, ils obtiendront un accès complet en tant qu'utilisateur d'origine et pourront effectuer des tâches qui nécessiteraient autrement une authentification.

Pour éviter de telles attaques, attribuez à l'utilisateur un nouvel ID de session en utilisant session_regenerate_id()lorsqu'il se connecte avec succès (ou pour chaque requête X). Maintenant, il a seulement l'ID de session et votre ancien ID de session (corrigé) n'est plus valide.

Quand dois-je utiliser session_regenerate_id()?

Comme le souligne symbecean dans les commentaires ci-dessous, l'identifiant de session doit être modifié à toute transition de l'état d'authentification et uniquement aux transitions d'authentification.

Lectures complémentaires:


2
Et qu'est-ce qui s'ajoute si le pirate fait le 20e appel? L'ID de session est modifié et il est le seul à posséder la session;))
fred727

@ fred727 Si le pirate a la chance de frapper le 20e appel, alors l'utilisateur aura un identifiant invalide et ne sera plus authentifié. Sans régénération du tout, le pirate informatique et l'utilisateur seraient authentifiés.
Bradmage

il peut également être utile d'appeler session_regenerate_id lors du stockage d'informations sensibles dans les sessions (donc pas seulement lors des transitions d'authentification)
Adam

Est-il possible de fixer la session si les informations de session ne sont pas dans un cookie? Je stocke les informations de session dans des fichiers sur mon serveur, est-il nécessaire de régénérer l'identifiant?
Gonzalo

"pour fixer (définir) l'ID de session (SID) d'un autre utilisateur" .... cela doit être remplacé par "pour fixer (définir) un ID de session (SID) sur l'ordinateur d'un autre utilisateur, puis l'utiliser après qu'il l'a authentifié "
Accountant م

25

Vous devez utiliser session_regenerate_id()pour arrêter le détournement de session et la fixation de session .

À partir de cette réponse Security.SE :

Le détournement de session fait référence au vol du cookie de session. Cela peut être accompli plus facilement lors du partage d'un réseau local avec d'autres ordinateurs. Par exemple chez Starbucks. Exemple ... un utilisateur avec la session Y navigue sur le site Web de James chez Starbucks. J'écoute leur trafic réseau en sirotant mon café au lait. Je prends l'utilisateur avec les cookies de la session Y pour le site Web de James et je configure mon navigateur pour les utiliser. Maintenant, quand j'accède au site de James, le site de James.

Depuis cette page Web :

La fixation de session est une technique d'attaque qui force l'ID de session d'un utilisateur à une valeur explicite. Selon la fonctionnalité du site Web cible, un certain nombre de techniques peuvent être utilisées pour «corriger» la valeur de l'ID de session. Ces techniques vont des exploits de Cross-site Scripting à la saturation du site Web avec des requêtes HTTP précédemment effectuées. Une fois l'ID de session d'un utilisateur corrigé, l'attaquant attendra que cet utilisateur se connecte. Une fois que l'utilisateur le fait, l'attaquant utilise la valeur d'ID de session prédéfinie pour prendre la même identité en ligne.

Quand utiliser

Lorsque l'utilisateur modifie / met à jour certaines entrées importantes (modification des mots de passe, des informations d'identification, des mots de passe oubliés, etc.) qui peuvent compromettre la sécurité du site ou la politique de confidentialité.

Voir également:

Guide de sécurité PHP: sessions

Fixation de session (bonne lecture)


22

Je pense que la question de l'intoxication de session a été assez bien couverte.

Pour répondre à la question "Quand dois-je utiliser ceci?" partie, il est important de prendre du recul et de réfléchir à ce que votre application fait avec la session. Ou, pour le dire autrement, c'est la question de sécurité clé à laquelle vous devez répondre

Si quelqu'un prenait la main sur cette session, que gagnerait-il?

Si tout ce que vous faites est de suivre des données autrement anonymes (l'utilisateur vient sur le site et vous les utilisez pour suivre ses visites), il n'y a aucune raison de régénérer une session. Un pirate de l'air ne gagnerait rien de valeur en saisissant cette session.

Cependant, de nombreux sites proposent des connexions. Une connexion change beaucoup de choses. Je peux accéder à mon profil. Je peux modifier les paramètres. Ainsi, un pirate de l'air peut vouloir accéder à mon compte, surtout si les utilisateurs normaux et administrateurs utilisent tous des sessions pour gérer la connexion. Ainsi, lorsque les gens viennent sur mon site et se connectent, je régénère la session. Cela ajoute une couche supplémentaire de sécurité que mon utilisateur nouvellement connecté est moins susceptible d'être détourné.

Chaque fois que nous ajoutons des données critiques à une session, vous devez envisager de régénérer l'ID de session. Si vous avez besoin de durcir votre application contre la fixation, une régénération aléatoire peut être utile mais je ne régénérerai JAMAIS à chaque demande. Par défaut, PHP stocke les sessions dans des fichiers sur le disque local. Vous ajoutez beaucoup d'E / S disque pour atténuer ce qui est un vecteur d'attaque relativement petit. Si vous avez vraiment besoin de plus de sécurité, je recommanderais d'utiliser le HTTPS complet plutôt que la régénération régulière (HTTPS rend la fixation très difficile à réaliser).


2
HTTPS ne change rien à la fixation.
kelunik

4
Mais cela rend les attaques de reniflage plus difficiles qui pourraient être utilisées pour obtenir l'identifiant de session en premier lieu.
demonkoryu

mon application php se déconnecte en quelques secondes, j'utilise la régénération, y a-t-il une limite de fichiers de session qui peuvent être créés ou y a-t-il une limite sur les identifiants régénérés qui pourraient être à l'origine de la déconnexion?
sqlchild

Pas généralement, non. Vous voudrez peut-être publier une question distincte à ce sujet
Machavity

16

Pourquoi devrais-je utiliser session_regenerate_id?

Vous devez l'utiliser pour éviter la fixation de session .

Quand dois-je utiliser session_regenerate_id?

Chaque fois que l'état d'authentification change, c'est principalement lors de la connexion et de la déconnexion.

Exemple

Bob est assis devant un ordinateur public et en parcourant stackoverflow.com, il y ouvre une nouvelle session. L'ID de session est enregistré dans un cookie (avec httpOnlyindicateur pour empêcher l'accès via javascript). Imaginons que Stack Overflow ait toujours activé HTTPS ainsi que l' secureindicateur défini pour le cookie.

Comment pouvons-nous voler la session maintenant?

Bob écrit l'ID de session. Il quitte l'ordinateur sans fermer le navigateur. Maintenant, Alice arrive sur cet ordinateur et voit que Stack Overflow est déjà chargé. Elle se connecte maintenant.

Nous sommes maintenant au stade où vous devriez utiliser session_regenerate_id. Si vous ne créez pas un nouvel ID de session ici lors de la connexion, Bob pourrait utiliser la session précédente qu'il avait écrite pour accéder à la session d'Alice et serait connecté en tant qu'Alice maintenant.


Mais jusqu'à ce moment où l' session_regenerate_id()émission, Alice peut accéder au compte bobs? Est-ce correct?
Akam

2
@akam - Il est tard, mais ça vaut le coup de répondre ... 1. Bob ne se déconnecte pas, Alice peut utiliser son login - 2. Bob se déconnecte, Alice ne se connecte pas, Alice peut utiliser son identifiant de session, mais il n'y a pas de connexion active pour accéder à ses données - 3. Bob se déconnecte, Alice se connecte, Bob utilise l'ID de session, il y a une connexion active, Bob accède aux données d'Alice. Mais pour être précis: dépendez de la sécurité des scripts, un identifiant de session ne signifie pas nécessairement que vous pouvez accéder aux données d'un utilisateur déconnecté, mais en général, c'est un risque possible et élevé.
codekandis

15

Vous pouvez l'utiliser pour une meilleure sécurité.

De cette façon, vous créez des identifiants de session pour une utilisation unique.

Disons que votre identifiant de session utilisateur est = 3

Un pirate a piraté votre client et récupère son session_id. Le pirate informatique peut donc utiliser ce cookie pour utiliser sa session.

Si vous avez du code comme

session_start();
session_regenerate_id();

vous pouvez modifier leur session chaque fois qu'ils utilisent votre site Web.

Maintenant, le pirate obtient sessionid = 3

mais vous avez changé de session après qu'il l'utilise donc votre

l'utilisateur a sessionid = 4 // auth

le pirate a session = 3 // null

Mais il y a un petit point, disons que vous utilisez la méthode de régénération et que votre client se connecte simplement au site Web et ferme le navigateur ou est inactif. Votre client a sessionid = 4 et si le pirate obtient des cookies à cet endroit, il aura le même sessionid.

Comme expliqué ci-dessus, vous pouvez protéger votre client contre le reniflement de données dans un sens, mais ce n'est toujours pas le cas pour résoudre ce problème pour de bon.

Mais ce sera beaucoup plus sûr si vous utilisez SSL enc.

Désolé pour mon mauvais anglais.


12

Un cas d'utilisation simple:

// User visits a webshop
$shopcart = new Cart();

Une session est lancée et une entrée est effectuée dans la base de données. Le panier de l'utilisateur est identifié par son identifiant de session.

// User orders items
$shopcart->add('123', 20);
$shopcart->add('124', 18);
$shopcart->add('127', 5);

Pour chaque produit ajouté, un enregistrement est réalisé dans ma table de panier. Également identifié par l'identifiant de session.

// User saves cart in order to use it later
$shopcart->save();

L'utilisateur a décidé de sauvegarder son panier. Il est maintenant attaché à son identifiant d'utilisateur.

// Regenerate session id for user to be able to make a new cart
session_regenerate_id();

L'identifiant de session est régénéré et l'utilisateur peut maintenant recommencer à créer un autre panier.


4

session_regenerate_id (): Impossible de régénérer l'identifiant de session - la session n'est pas active

if(session_status() == PHP_SESSION_ACTIVE)
{
    session_regenerate_id();
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.