Bonjour,
 
Je developpe un site en php qui devient assez frequenté.
 
Et j'ai eu la mauvaise surpprise d'apprendre que des utilisateurs se retrouvaient logués à la place d'autre utilisateur.
 
Par exemple l'utilisateur Toto arrive sur le site, et pouf par magie il se retrouve logué comme Dupont.
Ca ne m'est pas arrivé à moi, mais j'ai discuté avec l'utilisateur Toto qui me dit qu'elle n'a pas connaissance du password de Dupont et qu'elle n'a pas chercher à usurper l'identité de quelqu'un d'autre...
 
Est-ce que vous avez deja eu des problèmes avec des sessions en php4 ?
Comment éviter des collisions de sessions ?
 
merci d'avance
 
Fluminis

Ca pourrait pas être un bug dans ton code d'identification ?

Curieux ! Comme sielfried, je pense au code d'identification ! Est-ce que le code est unique pour chaque utilisateurs ? est-ce qu'il sont générés manuellement ou automatiquement ?
 
@+

Je ne vois pas ce qui cloche dans mon script de login, mais si vous voyer une faille je suis preneur
 

 
la page delog.php

 
et sur mes pages protégées :

Chouet, moi, "bizouille", je vais rendre visite à "tata" et je me conecte sur ton site. Tata qu'est passé dessus avant moi a gentiment remplis le cookie de son navigateur.
D'aprés toi, lequel des deux comptes tombe à l'eau?
 
Franchement, faire primer l'id et le mot de passe stocké dans le cookie par rapport à celui qu'on vient de saisir, ca me semble être une sécurité zéro vu que n'importe qui sera logué sous le compte du premier passé. Et sotcker le mot de passe en clair dans le cookie, ca me semble une sécurité triple zéro. (c'est si simple de copier un fichier d'un ordi à un autre ou de lire le contenu du fichier pour récupérer les valeurs qui sont dedans, et pire, avec firefox, le navigateur va gentiment nous donner les infos de lui même comme un grand)
 
Et

signifie : si un des deux est pas remplis alors on affiche le message d'erreur, mais si aucun des deux n'est remplis, on continu (xor <> or : xor = ou exclusif = "l'un ou l'autre mais pas les deux" or = "un ou l'autre ou les deux"
 
EDIT : Tu veux que je continus plus loin pour trouver d'autres gros bugs ou tu reprends ton code pour le corriger comme un grand?

Hum...
 
Pour ce qui du password en clair dans le cookie, je te l'accorde c'est une sécurité zéro, mais si tu veux que le l'utilisateur quand il revient sur ton site soit reconnu, tu veux stocker quoi ?
De toute facon quoi que tu stockes, il suffit de voler les cookies et hop tu es logué à la place de l'autre.
 
Pour le xor, c'est juste pour faire un message dans le cas ou l'un des deux est nul. Dans le cas ou les deux sont vides, c'est qu'il ne tente pas de se loguer, donc c'est un visiteur lambda et je n'ai pas a faire de traitement particulié.
 
Veux bien que tu continues à regarder mon code

Pour le password, tu stockes une valeur unique permettant d'identifier un utilisateur unique mais qui est pas son password!
 
T'as pas besoin de son password pour qu'il fasse une action

Un id quelconque à durée de validité déterminé. Ainsi, même si le cookie est volé, il ne poura pas servir éternellement. En, plus, en cas de vol de cookie, c'est moins génant de dévalider cet id que le compte complet.
 
En fait, le mieux que j'ai vu sur un site, c'est une possibilité de "ralonger" la durée de vie de la session pour pas avoir à se reconecter trop souvent sans que la conection ne reste éternelle.

il peut déjà commencer par crypter le password dans le cookie ou le stocker sous sa forme md5 (par ex). Bien entendu, il faut que le password soit stocké en md5 dans la bd... Au moins, comem ça, le password n'est pas connu de celui qui lira le cookie.

Certe, mais quelque soit l'élément inscrit dans le cookie, il faut aussi que la fin de validité de cet élément soit géré du côté du serveur et pas simplement par date de fin de validité du cookie. (date facilement falsifiable)

à mon avis c'est les noms des variables tu dois avoir le même nom de variable qq part et comme sur le serveur il doit y avoir register_global() activé eh bien quand t'utilises une variable qui a le mêem nom qu'une autre dans la session pouf! par magie ta variable session est changée, ton utilisatuer n'est donc plus toto mais tutu magique mais efficace ce qui perd l'utilisateur.

lordashram > Relis son code, il demandait simple à l'utilisateur de se loguer mais prenait en priorité ce qu'est contenu par le cookie et tant pis si c'était "toto" devant l'écran et pas son ami "tutu" qu'était passé la veille.

lordashram > ton idée est loin d'etre bete, j'ai en effet ce satanné register global à on sur le serveur, et je ne peux pas le changer.
ça pourrait venir de là !
Je vais chercher et je vous tiens au courant si je trouve quelque chose
 
omega2 > ça peut posé des problèmes dans certains cas je suis d'accord mais à mon avis, mon problème de collisions de sessions ne vient pas de là.

Tu peux modifier cette option en live sur ton script via la fonction  ini_set()

Si tu le dis, moi, j'ai jsute lu ton code et traduit en francais ce qu'il faisait.
Si maintenant tu dis que c'est pas ça, alors je te laisse chercher d'où ca vient mais n'empéche que t'as là un énorme trous de sécurité même s'il est pas à l'origine de certains cas.

on conseil, appelle toutes tes variables qui viennent sur la session avec le nom suivit de _s et pour le cookie pareil mais suivit de _c comme ça plus de collision tranquile.
Pour ce qui est de la reprise de ton code, rechercher remplacer $_SESSION[" et tu remplaces par $_SESSION["s_ et voilà toutes tes variables qui parleront à la session ne se collisioneront pas, et ça t'évitera de te retaper toutes tes pages unes par unes ( oui je sais là ça inverse ce que j'ai dit, mais pour de la reprise c'est plus simple à ce moment là...).
De plus pour le cookie avec login et mot de passe en clair, humm à mon avis le login tu peux le laisser, mais le password tu crées ton propre algorythme de codage, ça dissuadera le gars d'aller trop fouiller dedans. Le tout dans un p'tit tableau ça mettra du code de merde partout dans le cookie. Sinon si tes pass sont stokés avec une md5 tu mes le pass directos en md5 avec tout le bordel à côté ça devrait passer correctement...

lordashram > merci pour le conseil, je vais faire ça, ça sera en effet plus simple que de me retapper toutes mes pages une à une...