Discussion :

[JohnSly]

Bonsoir à tous !

Je me pose actuellement des questions sur les sessions php et le moyen le plus sûr de tester si un utilisateur est connecté.

Est-il suffisant de tester si une variable de session perso existe pour valider l'identification de l'utilisateur ?

Exemple : Lors de la soumission du formulaire de connexion, je check la bdd pour vérifier le nom utilisateur, le mot de passe et je créé une variable de session avec une valeur fixe. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$_SESSION['logged'] = 'ma-super-token-secrete';

Une simple vérification comme un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (isset($_SESSION['logged']) && ($_SESSION['logged'] == 'ma-super-token-secrete'))

est-elle suffisante ?

Si oui, merci de m'indiquer dans quelle mesure ?

Si non, j'ai lu sur plusieurs site que l'on pouvait ajouter une token qui se régénère à chaque page.
Quel est le moyen le plus optimisé sécurité/rapidité d'éxecution entre :

1) La token est envoyée par url puis vérifiée avec la variable de session puis regénérée. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if (isset($_SESSION['logged']) && isset($_GET['token']) && ($_SESSION['logged'] == $_GET['token'])) {
    $_SESSION['logged'] = regerate_token();
    //utilisateur loggé
}
else {
    //utilisateur non loggé
}

On écris chacun de ses liens avec la nouvelle token en paramètre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<a href="http://www.monsite.com/index.php?token=<?php echo $_SESSION['logged']; ?>">Mon Lien</a>

2) La token (unique pour chaque membre) est dans la BDD et on check les correspondances avec la variable de session. C'est le même principe sauf qu'au lieu de checker le $_GET['token'], on check la token dans la bdd (on store également le nom d'utilisateur dans les variables de session pour la correspondance). On profite pour update la token dans la bdd dans la fonction regenerate_token().

J'imagine la deuxième solution plus lourde (2 appels à la base tout de même) mais moins contraignante (pas de token dans l'url).

Merci pour vos réponses !

[bob633]

Perso, dans ma BDD je stocke un GUID (ton token unique) perso à chaque membre.

Dans mon cookies, je stocke le login, l'id et le GUID du membre.

Lorsque je récupère ce login et GUID par session dans mes pages, je vérifie d'abord que le login est bien associé au bon id puis au bon GUID (une requête SQL, ça tue personne). De ce fait si un petit malin trouve le moyen de modifier son cookies pour changer l'id ou le login, il a aucune chance de trouver le GUID du membre en question. S'il y arrive, c'est qu'il a réussi à se connecter à la BDD, mais là on est sur un autre problème.

[Invité]

Je ne sais pas si tu ne mélanges pas la gestion des sessions
avec cookies de session, et la gestion sans cookies

La gestion de session la plus courante maintenant est une gestion avec cookies de données.

Dés que tu fais session_start(); un cookies de session est envoyé
sur le micro de ton visiteur et contient la clé ultra fiable genre
hjqskdjjhuza!!5465445azezjjkkkkkkkkazeieazeziazi
Le serveur place alors dans son répertoire inabordable un fichier texte
hjqskdjjhuza!!5465445azezjjkkkkkkkkazeieazeziazi.txt
C'est ce fichier , donc sur le serveur qui contiendra toutes tes valeurs de session (pseudo, âge du capitaine ,page actuelle, etc....)

Que veux-tu de mieux

[JohnSly]

Merci pour ces réponses :

bob633 : Ta solution est celle que j'envisageais. Ce qui me chiffone, c'est en cas de vol de cookie. Un session_regenerate_id à chaque rechargement de page est-il suffisant ?

christele_r : Je sais que désormais, un cookie est utilisé pour les sessions (PHPSESSID). Et même problème, lors d'un vol de cookie.

Je sais qu'à ce stade là, c'est de la parano, mais c'est pour ma culture général

[JohnSly]

En y pensant, j'ai une autre question...

Pour s'assurer que les cookies proviennent bien de l'utilisateur initial, j'ai dans l'idée de garder certaines infos dans ma base (ip, user_agent) lors du login, puis de tester au chargement de chaque page :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
$ip = ''//à chercher dans la base
$user_agent = ''//à chercher dans la base
 
if ($ip == $_SERVER['REMOTE_ADDR'] || $user_agent == $_SERVER['HTTP_USER_AGENT']) {
   //identification validée et update dans la base de l'ip et du user_agent si un des deux changent
}
else {
   //l'ip et l'user agent ne correspondent pas... identification non validée
}

Est-ce, tout d'abord, vraiment utile ? Ensuite, quelles sont les chances (dans le cas d'un client avec ip variable) que l'ip et le user_agent changent tous les deux ?

Merci =)

[Invité]

Merci pour ces réponses :
christele_r : Je sais que désormais, un cookie est utilisé pour les sessions (PHPSESSID). Et même problème, lors d'un vol de cookie.

En réponse a tes deux messages
Un vol de cookies de données c'est déjas réservé a de bon hackeurs , hackeur qui mettent leur talent a des gros coups, pas ton "petit site"
ni au miens !
Alors un vol de cookies de session que tu ne trouvera pas sur ton micro
(ou dificilement) alors la c'est presque in-abordable !
A++
Christele