Discussion :

[psychoBob]

Alors on fait quoi ? On génère un numéro aléatoire avec md5() lors de l'identification, et on récupère les infos du membre en fonction de son md5() dans les pages qui le nécessite ?
je fais comme ça oui
avec en plus un id (aussi en md5) que je change à chaque appelle de page.

Ton fameux système, que tu nous as (généreusement) exposé ici, sur lequel je suis revenu ici, et auquel, je n'ai finalement rien compris, après avoir voulu le mettre en pratique. J'ai finalement essayé un système sur IP, que j'ai viré. Reste le session_regenerate_ip et peut être comme tu dis un code en lieu en place de l'id du membre dans la session

Et si deux membres se retrouvent par hasard avec le même md5() ? Au vu du temps d'une session, des paramètres aléatoire et unique (temps, ip, rand..) qu'il est possible de passer, faut vraiment etre un poissard pour avoir 2 id de session identiques au meme moment.

Bon et si je suis un super poissard, qu'est ce qui va se passer ?

[psychoBob]

avec en plus un id (aussi en md5) que je change à chaque appelle de page.

C'est justement le but de cet id md5() généré à chaque page qui m'échappe, ainsi que son mode de fonctionnement et ses conditions de réactualisation.

[wamania]

Ton fameux système, que tu nous as (généreusement) exposé ici, sur lequel je suis revenu ici, et auquel, je n'ai finalement rien compris

dans la pratique, ça fait en gros la meme chose que session_regenerate_id, mais pour chaque page.

Bon et si je suis un super poissard, qu'est ce qui va se passer ?

avec mon système de double ID de session, les 2 seront déco car ça correspondrait à un vol de session

C'est justement le but de cet id md5() généré à chaque page qui m'échappe, ainsi que son mode de fonctionnement et ses conditions de réactualisation.

je te conseil de regarder
http://www.developpez.net/forums/sho...d.php?t=143270
surtout la classe session (et sessionPHP), j'ai bcp commenté, tu devrais t'y retrouver

[psychoBob]

Bon alors je viens de remplacer l'id du membre enregistré dans la base par une id de connexion généré à l'identification.
Je le génère en faisant

Code :

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

1
2
3
 
$id=time();
$id=md5($id),

A priori aucune chance d'en avoir deux identiques, et si le pirate le chope il n'en fera rien ou du moins ne pourra s'en servir que tant que le membre ne se sera pas identifié une deuxième fois. (Je ne vois toujours pas ce que le hacker pouvait faire de l'id, mais bon en effet, autant ne pas lui donner d'informations appartenant aux membres, quelles qu'elles soient, je ne connais pas toutes les ficelles).

Par contre je ne pige pas/plus pourquoi/comment un id de session aléatoire pour chaque page. Certe cela déconnecte le pirate et le membre en cas de vol de session, ce qui répond au pourquoi.

Mais comment, je ne sais plus :
- Le membre vient de s'identifier, je lui donne un id de connexion comme dit plus haut, que j'envoie dans la base et dans la session.
Cet id ne bouge plus jusqu'à une prochaine connexion.
- En plus je lui donne un numéro provisoire pour la page, lors de l'affichage.
- J'envoie ce numéro provisoire lui aussi dans la base et dans la session.
- Le pirate se connecte, il change de page ce qui update le numéro dans la base, tandis que son numéro de session diffère de celui du membre.
- Le membre change de page, trimbale son numéro de session provisoire.
- Le script va vérifier dans la table si le numéro de session provisoire du membre est toujours le même que celui qui avait été envoyé dans la base à la page précédente.
- Comme le pirate à fait un update en changeant de page, le numéro de session du membre ne correpond plus à celui dans la base.
- Les deux PC explosent.
- Mission réussi, la session est déconnectée par le script de comparaison, le pirate est éliminé (le membre aussi mais un de perdu dix de retrouvés).

j'ai bon ?

[psychoBob]

Ok Wamania, j'ai réussi ton truc !

En efet j'ai tout testé (je crois), ça déconnecte si quelqu'un usurpe la session (il faut attendre que le membre change de page, mais bon, c'est déjà ça).


Par contre à la déconnexion j'obtiens l'erreur :

Code :

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

1
2
 
Warning:  session_destroy(): Session object destruction failed

Si tu as une idée...

[wamania]

tu as tout bon pour l'explication
la ou ce système bloque (si c'était parfait, ça se saurait), c'est comme tu l'as dit, il faut que le volé recharge au moins 1 fois la page après le vol pour que le voleur soit démasqué.
C'est à dire que si le vol à lieu au moment ou le membre arrete de naviguer, le voleur réussira son coup.
Pour éviter ça, le membre DOIT se déconnecter à la fin.

Je n'ai pas trouvé de réel solution pour ça. Mais je pense (mon avis perso) que ça reste le mieux pour eviter les vol de session (sans SSL of course), et surtout le meilleur rapport sécurité/souplesse

Warning: session_destroy(): Session object destruction failed

la, faut voir au niveau de ton code

[psychoBob]

Bon et bien j'ai eu beau chercher pour déconnecter le pirate avant l'utilisateur, je n'ai pas trouvé.

J'ai juste améliorer un peu le truc, en ajoutant un update à l'intérieur d'une condition qui désactive la session après x minutes d'inactivité.
Comme ça si l'inscrit reste x minutes sans utiliser, puis réutilise le site, il est certe déconnecté, mais au moins le pirate aussi.

Pour mon erreur

Code :

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

1
2
3
4
Warning: session_destroy(): 
Session object destruction failed in
 /home/site/scripts/liens-inscription.php 
on line (là où c'est en gras, dans les deux c'est pareil)

ça ne le fait plus qu'en j'enlève le :

Code :

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

session_regenerate_id(delete_old_session);

Juste en dessous du sessions start.
Mais je veux le conserver ce session_regenerate_id

[wamania]

Quelque chose me choque dans le script que tu as montrer hier soir.
Tu fais bien tout comme je l'ai expliqué, à une différence pres :
je m'explique :
Le but est d'eviter le vol de session, ce qui revient à faire croire au voleur qu'on est le vrai membre.
Pour identifier le membre du voleur, il faut se baser sur des propriétés qui leur sont propres (par exemple l'IP), et surtout (et c'est la que ton script a un soucis je pense) qu'ils soient coté client.
Ici, tu envoie un ID dans ta base (donc coté serveur) et 1 en session (donc coté serveur)
Si ton voleur pique l'ID de session PHP (le PHPSID), tu n'auras aucun moyen de savoir si c'est le vrai ou pas, car tu n'as aucun moyen de distinguer les clients entre eux.
L'idée serait donc maintenant d'en retirer un (celui de la base ou celui de session) et de la mettre dans un cookie.

Puis de faire les comparaison entre celui du serveur (base ou session) et celui du client (cookie) pour s'assurer que le client est bien celui qu'y sais identifié

wamania

[psychoBob]

Salut Wanamia,

Je n'avais pas mis la première partie du script, raison pour laquelle j'ai supprimé l'autre, celle d'hier soir.
La première partie déclenche lors de l'identification la chose suivante :
- Génération d'un id qui va rester fixe durant la connexion : envoie de celui-ci dans la base et dans la session.
- Génération d'un deuxième id provisoire (disons idP) : envoie de celui-ci dans la base et dans la session.
- Lors de la visite de chaque page, on va chercher si $_SESSION[idP] est toujours le même que celui dans la base de donnée. Ce qui ne peut plus être le cas si un pirate à affiché une page, car il a alors, dès son premier changement de page, updaté le champ idP dans la base avec le $_SESSION[id] qui lui a été attribué et qui diffère de celui du membre.
- Là il y avait un problème : le membre était déconnecté, puisque son idP en session ne correspondait plus à celui désormais dans la base car updaté par le pirate : la session était volé par le pirate, qui lui pouvait continuer à surfer, du moins tant que le membre ne se réidentifiait pas.
- Solution : si le membre est déconnecté parce que le pirate à updaté avant lui, alors lors de la connexion, le champ idP est de nouveau updaté. Conséquence: dès son nouveau changement de page, le pirate se retrouve à son tour avec un $_SESSSION[idP] qui diffère de celui dans la base. Il est déconnecté à son tour.

Honnêtement, j'ai testé plusieurs cas de figure, ça fonctionne bien, du moins dans mes tests...

Voilà un test que j'ai effectué :
a) Théorie :
- Le membre (M) se connecte. Il a un id fixe (id_F) et un id provisoire (id_P). Les deux sont envoyés dans la base et la session.
- Logiquement, si le pirate (P) se connecte, il va obtenir le même id_F mais un id_P différent.

b) Méthode :
- Je fais une modif dans mon script juste, pour que id_F soit toujours à 1 (afin que M et P aient le même id_F ce qui est le cas lors d'un vol).
- Pour simuler un vol de session, j'ouvre deux connexions, une avec IE et l'autre avec firefox. Le membre a IE, le pirate a firefox.
- Là nous avons deux connexions avec le même id_F mais des id_P différent.
- M surfe naturellement avec IE, tout va bien.
- P surfe à son tour.
- M change de page, se trouve déconnecté.
- P change de page, il est à son tour déconnecté.

c) résultat :
Tout le monde est déconnecté, c'est bon.

d) problème : tant que le membre n'a pas changé de page ou ne s'est pas déconnecté, le pirate surfe tranquille. Je crois que c'est le même problème que tu avais évoqué.
J'ai cherché (un peu) à faire en sorte que le pirate soit déconnecté directement, mais pas moyen, comme tu l'as dis, je pense que ça se saurait si le système était parfait.


Tu es rassuré Wamania ou tu y vois encore quelque chose à redire ?

**edit** J'ai rajouté un session_regenerate_id (true) sous le session_start(), à priori ça doit encore compliquer la vie du hacker, non ?

[wamania]

J'AI COMPRIS!!!
alors en fait, tu as utilisé pour tes test Firefox et IE.
Tu en as connecté 1, puis le 2ième et les 2 ont été déconnectés.
Car en fait, tu as simulé un vol d'identifiant et non un vol de session.
C'est à dire qu'en utilisant 2 explorateurs, tu as créer 2 sessions en parallèles pour le meme membre, ce qui les as déconnectés.
En gros, tu as réalisé un système, certe cohérent, mais qui ne fait qu'empécher un utilisateur de créer 2 sessions.
Ce n'empeche pas que si un gars récupère l'identifiant de session, il pourra voler la session sans pb.
De plus, ton système n'empeche le vol d'identifiant que qd les 2 sont connectés, ce qui veut dire que ça sert à rien le reste du temps.

Pour eviter le vol de session, il faut donc bien qu'il y ai comme je l'ai dit, un identifiant sur le serveur (BDD ou session) et 1 chez le client (par adresse ou cookies)

voila, j'ai mis du temps, mais bon...

[psychoBob]

Bon alors je viens de voir ta réponse Wanamia et effectivement je comprend ce que tu me racontes.

Mais je pige pas bien quand même ce que ça change d'avoir un id de session dans l'url ou dans le cookie plutot que dans la base de donnée en plus de l'id de session fixe, qui lui est bien enregistré dans la table lors de la connexion et le reste tout le long.

Ou alors justement c'est l'inverse, celui qui reste le même tout le long tu le laisses dans l'url, de manière à ce qu'il disparaisse lorsque l'utilisateur ferme la session.
Et là le pirate ne peut plus s'en servir alors que dans mon système il peut encore puisque l'id de session "fixe" est enregistré dans la base et le reste jusqu'à la prochaine connexion du membre...

On reprend tout stp? Je commence à devenir intelligent là.

**EDIT**
BON C'EST QUOI AU JUSTE UN VOL DE SESSION EN FAIT, POUR COMMENCER ?

[psychoBob]

Je reprend ton message en détail aussi, en plus du post juste au dessus :

J'AI COMPRIS!!!
alors en fait, tu as utilisé pour tes test Firefox et IE.
Tu en as connecté 1, puis le 2ième et les 2 ont été déconnectés.
Car en fait, tu as simulé un vol d'identifiant et non un vol de session.

Je vois pas la différence.

C'est à dire qu'en utilisant 2 explorateurs, tu as créer 2 sessions en parallèles pour le meme membre, ce qui les as déconnectés.

Oui

En gros, tu as réalisé un système, certe cohérent, mais qui ne fait qu'empécher un utilisateur de créer 2 sessions.

En bonus sans doute, mais c'était pas le but.

Ce n'empeche pas que si un gars récupère l'identifiant de session, il pourra voler la session sans pb.

Oui car les formulaires s'affichent si la variable $_identifiant_de_session est présente. Je pourrais en changer mais je vois pas l'intéret, si le pirate chope une session, il connaitra toutes les variables qu'elle contient.

De plus, ton système n'empeche le vol d'identifiant que qd les 2 sont connectés, ce qui veut dire que ça sert à rien le reste du temps.

Cela servait au moins à me laisser dormir tranquille. Au risque d'avoir une mauvaise surprise au réveil il est vrai.

Pour eviter le vol de session, il faut donc bien qu'il y ai comme je l'ai dit, un identifiant sur le serveur (BDD ou session) et 1 chez le client (par adresse ou cookies)

On met lequel chez le client ? Celui qui reste identique tout le long de la session et qui remplace l'id du membre, j'espère. Ou alors je pige plus rien.

voila, j'ai mis du temps, mais bon...

Mieux vaut tard que jamais, c'est moi qui captais pas de toute façon. Mais je voudrais bien y arriver quand même