esox_ch a écrit :
Oui mais je trouve quand meme beaucoup plus utiles les sessions. Elles ont une taille illimitée, nombre de variables illimitées, les risques d'interception de la part d'un tier ne sont pas plus hauts qu'avec les autres scripts (ton truc du id session passé dans l'url je comprend pas trop a quoi tu fais reference).
|
Attention quand meme, les sessions peuvent etre vulnerables mais sur le serveur.
Si tu es heberge sur un serveur mutualise, tes "voisins" peuvent "pirater" tes sessions, bon me semble que c'est pas possible s'il y a le safe mode, mais les sessions ne sont pas "secures".
Sinon, il me semble que sonikbuzz fait reference a l'id qui identifie les sessions. En effet quand tu cree une session cette derniere a une id. Cette id sert a la differencier des autres sessions. Mais voila, pour que le serveur sache a quel client appartient telle ou telle session, le client doit lui envoyer le session id.
La 2 methodes :
1) Surement la plus utilisee, c'est de stocker l'id de session dans un cookie chez le client. Cookie avec une duree de vie limitée qui n'est valable que le temps de la session du navigateur. Une fois ferme, le navigateur detruit le cookie.
2) Si le client n'accepte pas les cookies, alors on peut passer l'id de la session par l'url. Cette methode va "creer" des urls du type : "www.monsite.com/mapage.php?PHPSESSID=14524632155".
Ces 2 methodes sont "gerees par php", c'est pourquoi on a tendance a les oublier. Il existe d'ailleurs un parametre php pour lui dire s'il doit ajouter lui meme de facon autmatique le "PHPSESSID=..." a la fin des urls.
Enfin bref, dans les deux cas, l'unique chose a laquelle le client peut acceder est l'id de la session. Ici l'unique moyen pour lui de "pirater" une autre session c'est de connaitre son id... Les ids sont faits de telle maniere qu'ils peuvent difficilement etre "devines", donc a moins d'avoir un access quelconque au pc de la "victime" c'est quasiment "impossible".
La plus part du temps on prefere entrer par un autre endroit. Prenons un exemple. Admetons que vous stockez, dans un cookie, le "login" et le "md5" du password d'un user. Comme ca des qu'il revient sur le site, ce dernier detecte la presence du cokiie, puis apres verification du login et du mot de passe autorise l'utilisateur et lui cree une session.
Ici le hacker aura plutot tendance a pirater le site via une attaque du type de "sql injection" afin de recuperer un couple "login / md5(password)" que pirater la session php. Cette derniere etant plus dure a trouver, alors que le fait de pirater la bdd via une "sql injection attack" lui sera surement plus facile.
Avec cet exemple relativement simple on peut se rendre compte que le probleme ne vient pas forcement des cookies et/ou sessions, mais plutot de la facon generale dont le site est concu. Le simple fait que le site "reconnaisse" un utilisateur et le relogue sans lui redemander un password peut etre le point faible de votre site. Et dire qu'a l'origine vous ne vouliez que "faciliter la vie des utilisateurs" ont leur evitant de se re authentifier a chaque fois ...
Avec cet exemple on peut egalement voir que le fait que les infos soient "cryptees" ne changent pas bcp. Ici le mot de passe est "crypte" puisqu'il n'est pas stocke en clair dans le cookie. Neanmoins sa formee cryptee y est. Le probleme reside plus sur le fait que "la meme information" se trouve a la fois dans le cookie est dans la bdd. Une parade pourrait etre de ne pas utiliser le meme algo dans le cookie est dans la bdd. Mais un autre probleme survient... Generalement le mot de passe n'est jamais stocke en clair dans la bdd pour eviter des problemes si jamais la bdd vient a etre compromise. Mais s'il n'est pas sotcke en clair alors il y a pas vraiment de "moyen" pour pouvoir creer deux "cryptages" differents.
Si le password etait en clair il suffirait d'utiliser md5 dans un cas, puis par exemple sha-1 dans un autre. On pourrait toujours les "comparer" puisqu'on aurait une base commune. Mais cela n'est pas le cas, donc c'est pas vraiment faisable...
On pourrait "re crypter" le cryptage du mot de passe, mais cela ne fait pas bcp de difference, une fois que le hacker sait quel algo vous avez utilise pour "re crypter" le mot de passe ca ne sert plus a rien...
Ce qui pourrait eventuellement augmenter un peu le sentiment de securite serait de stocker en crypte le nom de l'utilisateur. Mais la un autre probleme survient.
Soit vous utilisez un "vrai" cryptage (donc reversible) et a ce moment une fois l'algo "devine" c'est comme s'il n'existait pas.
Soit vous utilisez un "faux" algo de cryptage (donc non reversible) et a se moment votre procedure de login ralentit proportionnelement aux nombre d'utilisateurs enregistres sur le site. Ben oui faut faire un boucle et a chaque fois comparer le cryptage de l'utilisateur que l'on teste avec la valeur du cookie. Il existe d'ailleur un autre probleme, il se peut que deux utilisateurs aient la meme valeur de "cryptage", bon il reste encore le "password" mais (et si ce dernier etait le meme ?)...
Enfin voila, apres cette longue tirade j'espere vous avoir montre que le probleme n'est pas vraiment la ou on le pense. Et je pense que la meilleure solution reste quand meme la session pour stocker "le boolean indiquant si l'user est logue" (stocker se bool ds un cookie n'est vraiment pas la bonne solution, car le cookie est facilement modifiable).
:
.
).
. (Tu peux me filer le contenu de ton cookie sur ton forum, tu verras je saurai me loguer. Maintenant c'est une mauvaise idée