Discussion :

[ixabro]

Bonjour,

je suis sûr qu'on vous a déja posé ce genre de questions, mais je tente toujours, biensur j'ai lu le FAQ avant posté sur ce forum. Mais celui ci n'a pas répondu à mes questions. Je me tourne alors vers vous developpiens.

Alors voilà, quand on créait une variable session : $_SESSION[X] = x, une id session est générée et disposée dans un cookie (à ce que j'ai cru comprendre).
Nous avons aussi à notre disposition la fonction session_generate_id() pour re-générer une nouvelle id de session. Cette fonction serait à placer après le session_start() de chaque page.

Je me pose le problème suivant :
Admetons qu'un attaquant A se soit approprié le cookie de la victime B. Si l'id de session ne change pas, A dispose des droits de B. Mais si l'id session change à chaque page alors A ne les possède plus. Justement là je ne sais vraiment si ça se passe ainsi.

Sinon j'aimerai comprendre ceci : ademettons, nous créons la variable session : $_SESSION[A] = a en $_SESSION[B] = a | notre id de session changerait ? Quel serait l'interet de changer le nom de session cela serait il être interessant pour la sécurité?

Ces notions de sécurité sessions sont un peu flou pour moi, veuillez m'en excuser.

Merci de lire mon post, en attentes de vos réponses.

[alain31tl]

Slt
Aucun intérêt de changer l'id de session, tout du moins dans ce cas de figure.
Soit tu utilises les cookies, soit les sessions php.

Dans le dernier cas, les variables de sessions sont enregistrées sur le serveur distant (domaine), et accessibles et/ou disponibles seulement depuis le navigateur de l'utilisateur , et ce, tant que ce dernier n'est pas fermé.
Par conséquent, je ne vois pas où est le probléme, ou les risques ?

C'est fait pour ça les sessions.

Note que j'ai mis en gras "seulement".

[sabotage]

seulement depuis le navigateur de l'utilisateur , et ce, tant que ce dernier n'est pas fermé.

Non : le lien entre l'utilisateur et la session est réalisée par l'id de session.
Plusieurs ordinateurs différents peuvent accéder à la même session en même temps tant qu'ils indiquent au serveur le meme id de session.
D'ou la possibilité de "vol de session" dont parle ixabro.

En fait il n'est pas nécessaire de changer l'id tout le temps mais seulement quand l'utilisateur change de droits.
Si notre pirate arrivait a deviner l'id courant d'un utilisateur, c'est le premier des deux qui interrogerait une page qui deviendrait le seul propriétaire de la session.

[alain31tl]

Plusieurs ordinateurs différents peuvent accéder à la même session en même temps tant qu'ils indiquent au serveur le meme id de session.
D'ou la possibilité de "vol de session" dont parle ixabro.

Slt
Je crée une session, elle est identifiée par un id de session.
Le serveur renvoie ces variables sur mon navigateur, sur mon pc.

Comment un autre utilisateur depuis un autre pc et un autre navigateur peut-il utiliser le même id. (?)

Si c'est possible, j'abandonne illico les sessions php.

[grunk]

Comment un autre utilisateur depuis un autre pc et un autre navigateur peut-il utiliser le même id. (?)

Avec une faille Xss par exemple. Un petit bout de js et op je reçoit l'identifiant de session stocké dans le cookie du mec qui aura cliqué sur la page infectée.

Encore plus simple , les serveur ou le SID est visible dans l'url. C'est très fréquent de voir des gens qui poste un lien avec à la fin PHPSESSID=azertyuiop.

[alain31tl]

Encore plus simple , les serveur ou le SID est visible dans l'url. C'est très fréquent de voir des gens qui poste un lien avec à la fin PHPSESSID=azertyuiop.

Slt
Ouais bon, jamais j'aurais l'idée de faire passer un id en get ou post quand j'utilise les sessions.
Dans ce cas, on ne parle plus de session., mais de passage de variables dans l'url.
Faut pas tout mélanger non plus.

et puis:

Avec une faille Xss par exemple. Un petit bout de js et op je reçoit l'identifiant de session stocké dans le cookie du mec qui aura cliqué sur la page infectée.

Là aussi, soit on raisonne cookie, soit sessions, ce qui n'est pas la même chose.
cookie : sauvegardé sur le pc de l'utilisateur, ok.
Ce qui n'est pas le cas pour une session php dure.

C'est quand même simple à comprendre et de bien distinguer les cookies des sessions.
Un session se lance depuis un pc/navigateur, et elle demeurera sur ce pc/navigateur tant qu'il restera connecté.
Je défie quiconque de venir récupérer mes variables de session depuis un autre poste pc/navigateur.
C'est enfantin pourtant.

Pour ixabro, l'id de session n'a vraiment que peu d'intérêt.
Sauf pour une sauvegarde sur une base données dans le cadre d'une utilisation multi-utilisateurs ou collaborative.
En fait, cet id de session n'est qu'un "réréfencant" de variables mises en mémoire....éphéméres puisque détruites lors d'une deconnection.
Celà dépend donc du cas de figure de l'application, mais il ne faut pas se focaliser sur cet id de sessions.
Honnêtement, j'utilise les sessions sur la plupart de mes applicatifs, et je me moque de savoir ou de connaitre son identifiant (id) puisque c'est lui qui me renvoie les variables utiles.
Puis de toute façon, je coupe mon navigateur, et tout est détruit.

[ixabro]

En effet mais là n'est pas la question. Justement la vérification constante des formulaires et autres se charge de veuiller à ce qu'aucun caractère spécial soit utilisé etc...
Sinon c'est l'arrivée en masse des failles XSS, CSS etc...
Je ne parlais pas vraiment de cela ...

Je voulais juste savoir si il y avait une stratégie pour éviter le vol session ou une manoeuvre d'un visiteur/utilisateur malvaillant qui pourrait être un problème à l'égard des autres membres du site.

En effet l'id de session d'un utilisateur B peut être volé à son inssue par un attaquant A.
Voilà où est mon problème, c'est extrèmement dérangant de savoir que A peut se connecter en tant que B et modifier des paramètres du profils etc... mot de passe aie ...
Peu importe les permissions comme me l'a fait remarqué Sabotage, si un utilisateur se retrouve sans possibilité de rentrer sur son compte... ça fait mal.

D'ailleurs je me demande comment il peut se connecter au site avec une id de session et un login... il ne faut pas aussi le mot de passe ? L'id permetterait d'outre passer cette attente ?

Sinon j'aimerai être sur de ceci :

$_SESSION['A'] et $_SESSION['B], ces deux sessions ont des id différentes sachant que chacune d'elle n'est pas lancée en même temps.

C'est à dire : connection 1 : -> $_SESSION[A] = ....
conncetion 2 : -> $_SESSION[B] = ....

Pour ces deux connections l'id session sera différente ou non ?

----------------

Sinon j'aimerai savoir si avec la fonction session_regenerate_id() on peut se tirer de quelques problèmes ? Cela sert il vraiment ou cette fonction ne désavantage pas les attaquant ?

Si j'en crois la fonction php, comment peut on voler l'id si elle change ... tout ceci est un peu flou.

[sabotage]

$_SESSION['A'] et $_SESSION['B] sont deux entrées dans la meme session.

comment il peut se connecter au site avec une id de session et un login... il ne faut pas aussi le mot de passe ? L'id permetterait d'outre passer cette attente ?

Dans le cas de fixation de session c'est l'utilisateur qui aura saisie son mot de passe, le pirate utilise la session parallelement à l'utilisateur une fois que celui-ci est connecté.
session_regenerate_id() permet d'eviter cette "fixation de session".
On peut egalement controler que l'ip ou même le navigateur de l'utilisateur ne changent pas en cours de route.