Discussion :

[psychoBob]

Bonjour,

J'avais ouvert un post pour comprendre comment empêcher (un peu) le vol de session.
Je pensais avoir compris, mais en fait je nage.
Voilà le but est de générer deux md5(), un lors de l'identification et un pour chaque page.
Avant l'affichage du corps des pages, on compare si tout est identique.
Logiquement, si un pirate à volé la session, il ne pourra rien faire car il aura des numéros différents.

J'ai donc fait cela :
1) lors de l'inscription

Code :

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

1
2
3
4
5
6
 
//on génère un numéro qui va être celui utilisé 
durant toute la session, pour empêcher les vols
 (en plus de celui initialisé sur chaque page).
$_SESSION['NumeroSession']=md5 (uniqid (rand()));
$_SESSION['NumeroSession2']=$_SESSION['NumeroSession'];

2) à l'affichage de chaque page :

Code :

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

1
2
3
 
$SessionNumeroPage=md5 (uniqid (rand()));
$SessionNumeroPage2=$SessionNumeroPage;

3) la structure de test pour savoir si il n'y a pas eu vol :

Code :

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

1
2
3
4
 
if($_SESSION['NumeroSession2']==
$_SESSION['NumeroSession'] AND $SessionNumeroPage2==$SessionNumeroPage);
{require('script/centre-definition.php');}

Voilà, à la vérité ça me parait nul : si un pirate vole la session, ce que j'ai fait ou rien c'est du pareil au même il me semble. Il récupère le md5() généré lors de l'identification et transmis à l'identique sur toutes les pages. Puis ses propres affichages génèrent un nouveau md5() unique sur chaque page, ce qui ne l'empêche en rien d'afficher les scripts à protéger.
Y'a un truc qui coince là.

(à la base c'est inspiré du principe d'enregistrement de l'ip mais ça pose trop de problème donc on remplace l'ip par un md5()).


Pourriez-vous m'éclairer SVP ?

[stunti]

Sauf qu'il n'a aucun moyen de connaitre le MD5 genere car il est stocke sur le serveur.

[psychoBob]

Tu parles du md5() généré à l'identification ?

Il est stocké en session donc il peut le sniffer non ? Et après il fait ce qu'il veut ensuite. C'est pas ça ? Que veux-tu dire au juste Stunti ?

**edit** elles circulent dans l'url mes variables de session (elles sont invisibles pour ne pas gêner le référencement mais bon, elles y sont quand même je crois).

[stunti]

ok, si ca circule dans les url c clair que la ca devient plus facile

[psychoBob]

Je vois pas comment faire autrement, ou alors pas cookie mais c'est mauvais.
Dans quel cas de figure te situais tu pour dire que le md5() est stocké sur le serveur ?

Bon et si j'expédie le md5() dans la base de donnée au moment de l'identification. Qu'est ce qu'il peut faire le pirate ?

[billoum]

En quoi l'enregistrement de l'IP dans la variable de session améliore la sécurité ? 2

Le 1 était déjà pas mal, que va donner la suite??

Sinon, pour ta question, je l'avais déjà posée à Wamania et il m'vait répondu ça:

oui, mais ils en ont
- 1 en commun, le session_id, et
- 1 qui différe, le session_id_page.

si celui qui a le mauvais appelle la page, il est déco, et le session_id est réinitialiser
l'autre avait tout bon, MAIS, le précedent a été déco et la session est morte.

Comme l'id session est commun, le deuxième est déco comme le premier.

Donc si j'ai bien compris, si le hacker vole les id_session, il devra vite les utiliser car si l'user demande une page:
- soit les id volés deviendront inutiles(il demande une page avant le hacker),
- soit la session sera détruite parce que l'id de page ne correspond pas avec celui de la session(il la demande après le hacker) et les 2 seront déconnectés.
[EDIT] il est donc nécessaire de se déconnecter proprement[/EDIT]


Mais bon, le mieux sera de demander à Wamania

[ePoX]

Salut,

**edit** elles circulent dans l'url mes variables de session (elles sont invisibles pour ne pas gêner le référencement mais bon, elles y sont quand même je crois).

Soit elle y est, soit elle y est pas Si elle n'y est pas, la propa du SID se fait par cookie.

Qd au systeme basé sur les md5 que tu présentes je le trouve bidon au possible.
Les Md5 de la session seront connu, puisque contenu dans la session, donc il ne servent à rien.
Et les md5 généré coté serveur sont EXCLUSIVEMENT égaux. Donc tester si toto == toto renverra EXCLUSIVEMENT VRAI.

Je ne sais pas quel problème pose L'ip, mais l'interet c'est d'avoir une information fiable de la part de l'internaute.
On compare l'IP du demandeur à l'IP de la session, et on sait si la session à changé de propriétaire de suite.

Sauf qu'il n'a aucun moyen de connaitre le MD5 genere car il est stocke sur le serveur.

Sauf que dans ce cas présent sa n'interese personne de connaitre les md5 généré, une fois que l'on à le SID le système est corrompu...
D'ailleurs il ne servent vraiment à rien, ces md5, encore une fois.



bbye

[stunti]

Ben si tu mets dans une session le client ne recupere que le SID ou un cookie contenant le SID. Les valeurs que tu mets en session sont stockees dans fichier sur le serveur.
Donc le client n'a jamais acces a ce qui se trouve en session.
en cas de vol de session si a l'identification tu mets un MD5 de l'ip (ou un truc plus secure et unique ) en session et que tu compares a chaque page que c'est la meme valeur, tu n'as pas de problemes car le pirate ne peut connaitre ce que le serveur stocke.

Heu...c'est clair ?

[ePoX]

Oui, mais dans ce que tu dis la tu introduis l'IP par hashage accessiorrement en MD5. Donc tu peux comparé deux sources différentes. Dans son système non.

[psychoBob]

Qd au systeme basé sur les md5 que tu présentes je le trouve bidon au possible.
Les Md5 de la session seront connu, puisque contenu dans la session, donc il ne servent à rien.
Et les md5 généré coté serveur sont EXCLUSIVEMENT égaux. Donc tester si toto == toto renverra EXCLUSIVEMENT VRAI.

C'est bien ce que je disais.

Je ne sais pas quel problème pose L'ip, mais l'interet c'est d'avoir une information fiable de la part de l'internaute.
On compare l'IP du demandeur à l'IP de la session, et on sait si la session à changé de propriétaire de suite.

Le problème c'est les proxis et les utilisateurs d'aol qui changent d'ip en cours de connexion, d'après ce qui s'est dit dans le post indiqué plus haut.


Bon alors je repose la question :
Je crée un champ "loginOk" dans la BD.
Lors de l'identification il passe à 1, en même temps que la session est initialisée.
Avant l'affichage des scripts, je test si il la session est active et si oui, je test aussi si loginOK est à 1. Le cas échant ça s'affiche, sinon non.
C'est bon là ? A priori le gars est obligé de s'être d'abord logé pour avoir les scripts, non ?

**edit**
Non en fait c'est nul aussi je crois. Bon alors qui a la solution donc ?

[ePoX]

Citation:
Qd au systeme basé sur les md5 que tu présentes je le trouve bidon au possible.
Les Md5 de la session seront connu, puisque contenu dans la session, donc il ne servent à rien.
Et les md5 généré coté serveur sont EXCLUSIVEMENT égaux. Donc tester si toto == toto renverra EXCLUSIVEMENT VRAI.

Tu as pas l'impression que c'était ce que je disais, EpoX ?

Sisi Mais comme tu poses la question, eh bien je réagit dessus.

Bon alors qui a la solution donc ?

lol

[psychoBob]

En fait je pige pas le processus.

Avec l'IP c'est très simple : on l'enregistre à l'identification, et on compare ensuite sur chaque page.

Donc comment remplacer l'IP par un md5() ?

[psychoBob]

En quoi l'enregistrement de l'IP dans la variable de session améliore la sécurité ? 2

Le 1 était déjà pas mal, que va donner la suite??

Sinon, pour ta question, je l'avais déjà posée à Wamania et il m'vait répondu ça:

Donc si j'ai bien compris, si le hacker vole les id_session, il devra vite les utiliser car si l'user demande une page:
- soit les id volés deviendront inutiles(il demande une page avant le hacker),
- soit la session sera détruite parce que l'id de page ne correspond pas avec celui de la session(il la demande après le hacker) et les 2 seront déconnectés.
[EDIT] il est donc nécessaire de se déconnecter proprement[/EDIT]


Mais bon, le mieux sera de demander à Wamania

Je n'avais pas vu que tu avais répondu billoum .

Donc peut être que tu viens d'éclairer une case : Il faut envoyer les deux md5() dans la base de donnée. Chaque fois que le visiteur change de page, il réactualise le md5() généré exprès pour la page. De fait si le pirate change de page, il n'a plus le même et est déconnecté.

Mais en fait, qu'est ce qui empêche un pirate de surfer aussi finalement ? Il va lui aussi updater et ça va sans arrêt interférer, tout le monde va être déconnecté au moindre changement de page du membre ou du pirate, non ?

[psychoBob]

(une question comme ça, vous les sécurisez vos sessions ? )

[billoum]

Ce que j'ai cru comprendre c que si l'un des deux échoue au test de l'id_page alors tu détruis la session ... et l'user devra refaire une authentification.

Donc le hacker pourra naviguer si l'user ne se déconnecte pas ou s'il ne demande plus de page.

[psychoBob]

A voilà :

On doit envoyer dans la base de donnée un md5() ET le passer en session.

A chaque nouvelle page on compare le numéro en session avec celui dans la base. Si ils sont identiques, on affiche, sinon on bloque.

En fin de page, on change le numéro stocké en session et on update dans la base de donnée.

Là si le hacker à visité une nouvelle page en même temps que le membre, celui-ci est bloqué. Ce qui est très bien car pendant ce temps là, le hacker peut continuer à surfer, ainsi, satisfait, cela évite qu'il s'énerve et fasse plus de dégat. Quand au membre qui s'est pirater sa session, bah tant pis pour lui.

C'est bon ?

[psychoBob]

Franchement avec un test sur l'IP c'est 1000 fois plus simple.

Pourquoi tous les tutos y compris sur développez parle du controle sur l'IP alors que sur le post mentionné plus haut, il est dit que ça pose problème pour les utilisateurs d'aol notamment.

Il parait que phpBB a un controle sur IP, alors les connectés via AOL ne peuvent pas utiliser les forums phpBB ?